[Date Prev][Date Next]
Re: Slurpd causes kernel panic due to huge replog file?
- To: Jukka Hienola <email@example.com>
- Subject: Re: Slurpd causes kernel panic due to huge replog file?
- From: matthew sporleder <firstname.lastname@example.org>
- Date: Fri, 25 Nov 2005 21:43:19 -0500
- Cc: OpenLDAP-software@OpenLDAP.org
- Content-disposition: inline
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S4Wp/meFefcZd7axJZClXEnUBu1vW2X3LAxhmEC6ionnGyJt08zeaCVYjv1ttedD/GuiEeoBHI8m40o6o10xqxcGWnEsym5ljv83Xe/LO8YPGIj+CA80y5KT1kajOZ5QWeoCm8R9NZrqbpBcMApWbmpiZkYlv2rnP8W/SgqSRMM=
- In-reply-to: <4386FF0A.email@example.com>
- References: <4386FF0A.firstname.lastname@example.org>
I've run replog files for a pretty long time and never seen slurpd
grow very much in memory usage while it processed it. Your kernel
panic is obviously a linux problem and it seems odd that a 2.6 kernel
would be running on a filesystem with a 2gb limit. However, it should
be pretty easy to just engineer a fake replog file to see if you can
reproduce the problem while tracing/debugging slurpd.
On 11/25/05, Jukka Hienola <email@example.com> wrote:
> A couple of days ago my master LDAP server's IP address changed. After
> the change I forgot to open ports on my firewall to allow replication of
> my LDAP directory with my slave LDAP server. Due to this, requests to
> slave server were written to master server's LDAP directory, but
> replication of master server's directory to slave server didn't succeed.
> As a result, my replog file size did grow until reached it's maximum
> size on my master server's filesystem. After I noticed that replication
> doesn't work, I located the problem to firewall sttings and fixed that.
> I restarted my slapd and slurpd daemons, and I saw replication requests
> processed until all memory vere consumed on my master system and system
> crashed with kernel panic. Several times.
> I'm not sure, but I assume that the size of replog file was too big and
> my system has not enough memory (1GB RAM + 1GB swap). The memory were
> consumed little by little as replication proceeded, until I run out of
> Next I backed up replog file and splitted the original file into smaller
> bits, which I successfully replicated on my slave server's LDAP
> directory with slurpd.
> So, my question is, if anyone has encounter similar situation? Could the
> reason really be the size of replog file, or corrupted replog file?
> That's all I could think of. If so, is there any way to split replog
> file into smaller slices of some maximum size (depending of your
> filesystem limitations) if needed, e.g. slapd.replog.0, slapd.replog.1,
> ... slapd.replog.n, which could be replicated one after another (e.g.
> *.0,*.1, ..., *.n)?
> I've tried to find something like that from OpenLDAP documentation, but
> to be honest, I found it very concise.
> In fact, I suppose it wouldn't be very difficult to make such a changed
> to OpenLDAP code... maybe I'll try.
> ... and I'm using RHEL4 on both master and slave servers (kernel
> 2.6.9-22) and OepnLDAP 2.2.13-4.
> Jukka Hienola
> IT Services Administrator, Department of Physical Sciences,
> University of Helsinki, firstname.lastname (a) helsinki.fi,
> tel. +358 (0)9 191 50713, fax. +358 (0)9 191 50610