Re: FreeBSD 5.4 - filesystem full
Booting into single-user via serial console, KVM, KVM-over-IP, or iLO/LOM (if HP/Compaq) is sufficient. If you have servers which are remote and you lack any of these features, I'm both surprised and not sure what to tell you. You'll encounter this problem with any OS, not just FreeBSD. I'm looking for something similar to /forcefsck file on the linux systems. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)718-3322, 718-3115(fax) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 - filesystem full
On Wed, 12 Nov 2008, Adrian Penisoara wrote: What kind of applications are you running on the machine ? Are they mmap'ing files on the filesystem in quesiton (which one ?) ? mainly apache, sphinx's search daemon and several perl scripts AFAIR even if you delete a big file the disk space may not be reclaimed if a process still has the file open. but even if you run df -ki in the exact moment of when the filesystem full messages are appearing in the logs, it reports of having 40G free and a lot of free inodes. If you reboot the machine or restart some of the applications, does the issue disappear ? after rebooting during several days the issue doesn't arise, then it repeats again. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)718-3322, 718-3115(fax) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4 - filesystem full
I have an old enough server with FreeBSD 5.4 which from time to time complains about filesystem full. But the problem is that the partition in question has about 15G free space and more than 1000 free inodes. Then all by itself the error dissapears, only to be repeated several hours later. What can it be and where to look? The server runs mainly apache and sendmail, nothing special. Thanks and regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)718-3322, 718-3115(fax) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 - filesystem full
On Wed, 12 Nov 2008, Jeremy Chadwick wrote: I would start by taking the machine down, booting it into single-user, and running fsck -y. background fsck does not catch all errors. Background fsck has been turned off from the beginning, and a couple of weeks ago when there was a power break, full fsck -y was done all the same. But you're right, running fsck -y once again will not harm. Also, how soon do you check the box to see how much space/free inodes it has after receiving a filesystem full error? Are we talking I checked it 4-5 hours later, or I checked it 30 seconds after? I checked it several minutes after. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)718-3322, 718-3115(fax) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4 - filesystem full
I have an old enough server with FreeBSD 5.4 which from time to time complains about filesystem full. But the problem is that the partition in question has about 15G free space and more than 1000 free inodes. Then all by itself the error dissapears, only to be repeated several hours later. What can it be and where to look? The server runs mainly apache and sendmail, nothing special. Thanks and regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)718-3322, 718-3115(fax) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 - filesystem full
I would start by taking the machine down, booting it into single-user, and running fsck -y. background fsck does not catch all errors. Okay then, are there any ways of performing it remotely, without my going to the data center and standing near the server for an hour while it checks? I mean are there any civil ways, or only running reboot -qn and praying? :) Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)718-3322, 718-3115(fax) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
httpd and /etc/pwd.db
Hello, I have a problem with apache httpd daemon which sporadically starts creating child processes (and never killing them), which takes place after writing the following into the syslog and system console: httpd: /etc/pwd.db Can it be the problem with the scripts working under mod_perl, or httpd itself? Httpd is Apache/1.3.27 (Unix) mod_perl/1.27 PHP/4.2.3, FreeBSD 4.5. Thank you Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
SIGPIPE in popper
Hi everyone and Merry Christmas! I have the following problem: after moving cucipop popper daemon to FreeBSD 4.9 from 4.5, the popper often terminates with a SIGPIPE, even if the client resides on the same server. It never occured on FreeBSD 4.5. It seems as though the tcp connection breaks unexpectedly due to some reason at random times. Can you give me any hints how to solve this? Thanks a lot Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
perl_call_sv
Hi everyone, when trying to run some perl program (Interchange to be precise), I get the following error: /usr/libexec/ld-elf.so.1: /usr/local/interchange/lib/auto/Safe/Hole/Hole.so: Undefined symbol perl_call_sv The system is a fresh install of 4.9-RELEASE. Any help is greatly appreciated. Regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
libjavaplugin_oji.so
Hi guys, can anybody please send a file to me or give a link where I can download it myself: jdk1.3.1/jre/plugin/i386/ns600/libjavaplugin_oji.so I'm trying to run Mozilla and all worked well except java support, because the compiling of jdk13 didn't work due to some weird errors, and ftp/file search for this file didn't give positive results either. Thanks a lot! Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libjavaplugin_oji.so
Jon, you're right about me building JDK from ports, but I altready have the JDK binary installation on this server installed which was transfered here from some another server, but lacking the libjavaplugin_oji.so file. So what I need is just adding this single file to the already installed JDK. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Thu, 30 Oct 2003, Jon Mercer wrote: It sounds like you are trying to build the native JDK 1.3 from ports. In order to do that you need to have a JDK already installed to 'bootstrap' from. The default method as specified in the makefile seems not to be working. Given I also had this problem, I found the best way around it was to install the Linux Blackdown JDK before attempting to install the BSD native one required for Mozilla. Once the Linux JDK is installed you can return to the build of the native JDK and specify WITH_LINUX_BOOTSTRAP=yes. Once I had done that all worked fine. Jon Varshavchick Alexander wrote: Hi guys, can anybody please send a file to me or give a link where I can download it myself: jdk1.3.1/jre/plugin/i386/ns600/libjavaplugin_oji.so I'm trying to run Mozilla and all worked well except java support, because the compiling of jdk13 didn't work due to some weird errors, and ftp/file search for this file didn't give positive results either. Thanks a lot! Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Load Average more than 400
On Tue, 28 Oct 2003, Charles Swiger wrote: What does ps auxw look like when you have this load spike? Nothing unusual - mysqld processes, nothing else... Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Load Average more than 400
On Tue, 28 Oct 2003, Daniela wrote: Watch your top (or ps -ax) output. Anything odd there? Nothing odd - many mysqld processes as usual... Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Load Average more than 400
On Tue, 28 Oct 2003 [EMAIL PROTECTED] wrote: MySQL has done this to me after an unclean shutdown. Try stopping mysqld and running myisamchk -r on all tables. first of all, I use mostly innodb tables, and secondly, and besides, there was indeed an unclean shutdown recently but already several hours had passed so it couldn't be the cause of it as it seems. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Load Average more than 400
Hi gurus, can you please hint as what parameters I have monitor to find the cause of sudden splashes of load of a FreeBSD 4.6.2-RELEASE server? This box is acting as a database/mysql server and periodically goes up to 400 of load average values and then gradually returns to a normal 4-5 value. The server is a dual Xeon with 4G phisical memory, mysql 4.0.7/linuxthreads. During the highest load, the amount of Inact memory remains of about 2G, and swap is used only minimally, so this cannot be the case. There are no messages in a system log or mysql log. Any help is greatly appreciated, thanks is advance Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nmbclusters and nmbufs
On Tue, 19 Aug 2003, Jack L. Stone wrote: You can modify those on fly without a reboot with: sysctl kern.nmbclusters=n (n being the number of choice) No, it doesn't work: sysctl: oid 'kern.ipc.nmbclusters' is read only You can then put the statements in the /boot/loader.conf and will load on next boot as alternative to changing the kernel. I modified the kernel here. Yes, adding them to /boot/loader.conf and rebooting made the trick, thanks. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nmbclusters and nmbufs
On Tue, 19 Aug 2003, Alex de Kruijff wrote: Can anybody advise me please if I want to increase nmbclusters option in kernel, can I just type sysctl kern.ipc.nmbclusters=16384 without rebooting the server, or is the only way to set the NMBCLUSTERS option in kernel, install the new kernel and reboot? These variable are normaly readonly, so I think you do need to reboot. And secondly, also I need to increase nmbufs kernel option, but there seems to be no such option in LINT, what should I tweak? sysctl kern.ipc.nmbufs=32768 without rebooting or kern.ipc.nmbufs=32768 in /boot/loader.conf and reboot? It does exist: options NMBUFS=4096. Yes, but I guess I must have said that the system version is 4.5 and this options didn't exist then. You seen to be low on a lot of resources. It could be an idee to set ``maxusers'' to a higher setting. These days a lot of varibles base there value on maxusers. Maxusers is already set to a high value, but due to the extensive network activity nmbufs and nmbclusters seemed to be lacking. Thank you for the advices. -- Alex Articles based on solutions that I use: http://www.kruijff.org/alex/index.php?dir=docs/FreeBSD/ Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
How to delete unix socket entry
Hi people, I had a wrong-behaved server application which opened a unix socket to respond to incoming connections, so after the socket was opened, the application core dumped each time it was launched. As a result, 'netstat -f unix' now shows a lot of not-needed active entries. Is there any way to delete these addresses, or will they eventually die by themselves? Regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: differentiating apache children from parents ?
you can look at the parent pid of the process in question wether it is 1 or not: ps xa -oppid -p _PID_ But depending on what you're trying to do afterwards (for example kill the process if you determine by some external script that there are too many apaches running and you're not satisfied with the native apache process maintanance mechanism), there can be better ways... Regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Fri, 24 Jan 2003, Josh Brooks wrote: Date: Fri, 24 Jan 2003 05:22:00 -0800 (PST) From: Josh Brooks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: differentiating apache children from parents ? Hello, Is there any way to tell, simply from /proc info and/or ps output if a certain httpd PID is a child or the parent ? If yes, is this method applicable on any OS (linux) ? thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: differentiating apache children from parents ?
Yes you can kill it if the pid is not 1, presuming you're not killing it during of a query processing. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Fri, 24 Jan 2003, Josh Brooks wrote: Date: Fri, 24 Jan 2003 05:33:27 -0800 (PST) From: Josh Brooks [EMAIL PROTECTED] To: Varshavchick Alexander [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: differentiating apache children from parents ? I want to kill apache children that exceed a certain memory size - but I want to make sure only to kill children. Is your method a workable way of doing that ? That is, I would test it and if it is +not+ 1 then I would be ok to kill it, since it is not the parent ? On Fri, 24 Jan 2003, Varshavchick Alexander wrote: you can look at the parent pid of the process in question wether it is 1 or not: ps xa -oppid -p _PID_ But depending on what you're trying to do afterwards (for example kill the process if you determine by some external script that there are too many apaches running and you're not satisfied with the native apache process maintanance mechanism), there can be better ways... Regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Fri, 24 Jan 2003, Josh Brooks wrote: Date: Fri, 24 Jan 2003 05:22:00 -0800 (PST) From: Josh Brooks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: differentiating apache children from parents ? Hello, Is there any way to tell, simply from /proc info and/or ps output if a certain httpd PID is a child or the parent ? If yes, is this method applicable on any OS (linux) ? thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Big directory size
Yes, the kernel has a dirhash option. Thank you for the answer. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On 13 Jan 2003, Lowell Gilbert wrote: Date: 13 Jan 2003 16:36:06 -0500 From: Lowell Gilbert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Big directory size Varshavchick Alexander [EMAIL PROTECTED] writes: I had a directory with a lot of files (about 100 000), and naturally, the size of the directory entry itself was big enough (about 1M). Now I've split all these files to different subdirectories, to increase the system performance. The major directory entry size didn't change, however such a big value is not needed now. Now here is a question - can an unnessesary big value of a directory entry size harm the system performance? I guess it does not, is it correct? If the files were created without the dirhash code in your kernel, it certainly could. It still could with the dirhash, but shouldn't be noticeable at the 100,000-file level. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Big directory size
Yes, talking about a directory entry size, I meant just the size of inode entries, not the summary size of directory contents... Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Mon, 13 Jan 2003, Daniel Bye wrote: Date: Mon, 13 Jan 2003 17:28:50 + From: Daniel Bye [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Big directory size On Mon, Jan 13, 2003 at 02:45:16PM +0300, Varshavchick Alexander wrote: Hello, I had a directory with a lot of files (about 100 000), and naturally, the size of the directory entry itself was big enough (about 1M). Now I've split all these files to different subdirectories, to increase the system performance. The major directory entry size didn't change, however such a big value is not needed now. Now here is a question - can an unnessesary big value of a directory entry size harm the system performance? I guess it does not, is it correct? This is just speculation, but I would imagine the key factor affecting performance would be more to do with the number of inode entries in a given directory, than with the size of the directory's contents. However, I am no file system expert, this is just my gut feeling... -- Daniel Bye PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Big directory size
Hello, I had a directory with a lot of files (about 100 000), and naturally, the size of the directory entry itself was big enough (about 1M). Now I've split all these files to different subdirectories, to increase the system performance. The major directory entry size didn't change, however such a big value is not needed now. Now here is a question - can an unnessesary big value of a directory entry size harm the system performance? I guess it does not, is it correct? Thanks Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
Hi, Despite the increased KVA space (2G now) and the perfect patch of the pthreads mechanism made by David, the server's lock-ups persist. Comparing this server's vmstat output with some other's which doesn't have the similar problem, I noticed that the FFS node value seems to be abnormally high - 75113K from 102400K possible. What becomes with the system if this value bumps even closer to the limit, and how it can be put into place? And more of it: which other parameters must be examined first? If I'll send the output of vmstat -z and vmstat -m will you look at it please? Thanks a lot, regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Mon, 9 Dec 2002, Dmitry Morozovsky wrote: Date: Mon, 9 Dec 2002 22:32:04 +0300 (MSK) From: Dmitry Morozovsky [EMAIL PROTECTED] To: Varshavchick Alexander [EMAIL PROTECTED] Cc: David Schultz [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: maxusers and random system freezes On Mon, 9 Dec 2002, Varshavchick Alexander wrote: VA the server went to a swap, because it occurs practically instantly, and VA this state goes for hours. The system is lacking some resources, or may be VA a bug somewhere, can you give any hints to it? Hmm, what about logging vmstat/pstat/netstat -m/sysctl vm ? Possibly to remote machine via remote syslog? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
There seems to be archive posts already on the subject, the most informative of them is here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1093170+1102546+/usr/local/www/db/text/2001/freebsd-stable/20010923.freebsd-stable Did this issue got solved somehow? More specifically, how the size of the FFS node malloc area can be increased? Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Thu, 19 Dec 2002, Varshavchick Alexander wrote: Date: Thu, 19 Dec 2002 13:29:18 +0300 (MSK) From: Varshavchick Alexander [EMAIL PROTECTED] To: Dmitry Morozovsky [EMAIL PROTECTED] Cc: David Schultz [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: maxusers and random system freezes Hi, Despite the increased KVA space (2G now) and the perfect patch of the pthreads mechanism made by David, the server's lock-ups persist. Comparing this server's vmstat output with some other's which doesn't have the similar problem, I noticed that the FFS node value seems to be abnormally high - 75113K from 102400K possible. What becomes with the system if this value bumps even closer to the limit, and how it can be put into place? And more of it: which other parameters must be examined first? If I'll send the output of vmstat -z and vmstat -m will you look at it please? Thanks a lot, regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Mon, 9 Dec 2002, Dmitry Morozovsky wrote: Date: Mon, 9 Dec 2002 22:32:04 +0300 (MSK) From: Dmitry Morozovsky [EMAIL PROTECTED] To: Varshavchick Alexander [EMAIL PROTECTED] Cc: David Schultz [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: maxusers and random system freezes On Mon, 9 Dec 2002, Varshavchick Alexander wrote: VA the server went to a swap, because it occurs practically instantly, and VA this state goes for hours. The system is lacking some resources, or may be VA a bug somewhere, can you give any hints to it? Hmm, what about logging vmstat/pstat/netstat -m/sysctl vm ? Possibly to remote machine via remote syslog? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
Hi David, Thanks, you're a genuis, didn't you know that? Your patch worked perfectly :) However, it didn't solve the random freezes problem. The server felt relieved a bit, load average value pushed down a little, so when the server is working, this change did him good. Now more about a state when the server sleeps. It behaves as though the load average has suddently fired to some immense value - the system responds to ping, but all other activity has almost halted. It's not like the server went to a swap, because it occurs practically instantly, and this state goes for hours. The system is lacking some resources, or may be a bug somewhere, can you give any hints to it? My best wishes Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Fri, 6 Dec 2002, David Schultz wrote: Date: Fri, 6 Dec 2002 05:47:24 -0800 From: David Schultz [EMAIL PROTECTED] To: Varshavchick Alexander [EMAIL PROTECTED] Cc: Terry Lambert [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: maxusers and random system freezes Thus spake Varshavchick Alexander [EMAIL PROTECTED]: On Fri, 6 Dec 2002, David Schultz wrote: Thus spake Varshavchick Alexander [EMAIL PROTECTED]: Well, now I made KVA space 2G, we'll see later on if it helps to get rid of the sudden system halts, but for some reason a side-effect has appeared: pthread_create function returns EAGAIN error now, so I had to recompile the software using it with linux threads to make it working. With the old kernel these pieces worked without problems. Can it be that somehow the enlarged KVA space messed up with the threads mechanism? I'm not a pthreads expert, but my best guess is that your program tried to create a thread with a stack address that was too high. Remember that with a 2 GB KVA, user processes have only 2 GB to play with instead of 3 GB, so attempting to mmap() a stack above about 2 GB would cause pthread_create() to return EAGAIN. Yes this makes sense, however this call to pthread_create didn't specify any special addresses for the new thread. The pthread_create was called with the NULL attribute which means that the system defaults were being used. Something in the system has gone wrong... I just glanced at the source in -STABLE, and it appears to be a pthreads bug. (Then again, maybe I'm missing something, since nobody seems to have noticed this before.) The default address at which new thread stacks are created is just below the main stack. This address is based on the lexical constant USRSTACK, but it should be initialized in uthread_init() based on the kern.usrstack value returned by sysctl. (The correct value is already used to map the main stack's red zone.) The result is that you need to make world and recompile any apps statically linked against pthreads after building your new kernel in order to get things to work. I don't have time to fiddle with pthreads until after Christmas, but you might see if the following patch (against -STABLE) helps when you reduce the configured KVA size without remaking pthreads. Index: uthread/uthread_init.c === RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v retrieving revision 1.23.2.10 diff -u -r1.23.2.10 uthread_init.c --- uthread/uthread_init.c2002/10/22 14:44:03 1.23.2.10 +++ uthread/uthread_init.c2002/12/06 13:41:06 @@ -245,6 +245,8 @@ len = sizeof (int); if (sysctl(mib, 2, _usrstack, len, NULL, 0) == -1) _usrstack = (void *)USRSTACK; + _next_stack = _usrstack - PTHREAD_STACK_INITIAL - + PTHREAD_STACK_DEFAULT - (2 * PTHREAD_STACK_GUARD); /* * Create a red zone below the main stack. All other stacks are * constrained to a maximum size by the paramters passed to To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, David Schultz wrote: In FreeBSD, each process has a unique 4G virtual address space associated with it. Not every virtual page in every address space has to be associated with real memory. Most pages can be pushed out to disk when there isn't enough free RAM, and unallocated parts of the virtual address space aren't backed by anything. (Referencing an unmapped page that the system doesn't know about generally causes the program or OS to crash. You've probably seen these as ``segmentation faults'' and ``page fault in kernel mode'' panics.) To simplify things, the kernel is mapped into a fixed location in every address space. The KVA parameter controls how big a chunk the kernel gets; the remainder goes to user processes. However, only the part of the KVA reservation that the kernel actually uses is wired to physical memory. For example, if you have a 1 GB KVA reservation and the kernel allocates only 20 MB of RAM, then only 20 MB of RAM is needed (plus some epsilon if you want to be picky), but in theory, the kernel could allocate and manage up to 1 GB of data. You don't lose extra physical memory for increasing KVA, but a large KVA size does constrain the virtual address space available to user processes. Thank you David for such an excellent explanation. So if sysctl reports vm.zone_kmem_pages: 5413 vm.zone_kmem_kvaspace: 218808320 vm.kvm_size: 1065353216 vm.kvm_free: 58720256 does it mean that total KVA reservation is 1065353216 bytes (1G) and almost all of it is really mapped to physical memory because only 58720256 (56M) is free, and the server is balancing on the edge of crashing with KVA going out? Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, Terry Lambert wrote: ... Are you talking primarily about SHMMAXPGS=262144 option here? Then may be it'll be oevrall better to reduce it and make KVA space 2G, to leave more room for user address space? That's the one I was referring to, yes, but you didn't post your whole config (please do *NOT* post it; I can't spend the time on going over it line by line). All other config options are pretty much like the default ones. Tuning is a skill; it can be plotted out as a cookbook recipe, but it takes a lot of work to do that, and no one has volunteered. Basically, to write out a cookbook, you have to know where every byte of memory is going in the kernel, and what tunables impact each other, and how they are related. Once you know that, you could easily write a program to kick out a configuration file for various usages, or even modify the code to auto-tune itself (everything by KVA space, which impacts the base address that the kernel gets linked to... unless you compile the entire kernel PIC, which I do not recommend). But knowing the information is hard. I know it for 4.3 and 4.4. You're right, expecially for getting an _ideally_ tuned kernel. However in a real life, a specialist cannot have an absolute knowledge about _all_ server and other issues, so practical solutions are being looked for in items which can arise. Of cause, no one is arguing that a basic knowledge is needed and required. ... If you are having system freeses at random, and you want to fix them instead of living with them, some experimentation is going to be inevitable. I don't know enough about your installation to be able to give you a kernel config file to use that will magically fix all your current issues for you, and prevent future issues from coming up. That's going to have to be up to you. Surely, I'm just trying to reduce the experimental attempts as much as possible and to rise the chances of success for each new configuration version. ... No, the swap is very slightly used on this server, and the total swap size is 2G. It doesn't matter. The amount of swap the kernel allocates page tables for is based on the amount of physical RAM in the machine. You pay for the page tables whether you use them or not, for swap, for the kernel, and for any memory which you permit to be allocated at interrupt time, plus any allocations that occur after you are up and running, until you run out of physical RAM. This is one of those things you just have to know about how the kernel uses virtual memory, if you are going to be a skilled kernel tuner. As a rule, swap should be at least physical memory size + 64K on any system that you need to be able to get a system dump from, since it needs to dump physical RAM. If you are not worried about the machine falling over, then you can ignore that. Note that man tuning suggests 2* physical RAM for swap. PS: I am going to be out of touch (able to download, but not send email) for the next couple of days... up to a week. If you have more questions, and they can't wait, you will need to ask someone else. Thank you for all your advices, they've already helped a bit. Have luck in your trip or elsewhere. - Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Fri, 6 Dec 2002, David Schultz wrote: vm.zone_kmem_pages: 5413 vm.zone_kmem_kvaspace: 218808320 vm.kvm_size: 1065353216 vm.kvm_free: 58720256 does it mean that total KVA reservation is 1065353216 bytes (1G) and almost all of it is really mapped to physical memory because only 58720256 (56M) is free, and the server is balancing on the edge of crashing with KVA going out? Yes, 56 MB of unreserved kernel virtual memory (modulo fragmentation) is probably pushing it for a busy server. Try bumping KVA_PAGES. Well, now I made KVA space 2G, we'll see later on if it helps to get rid of the sudden system halts, but for some reason a side-effect has appeared: pthread_create function returns EAGAIN error now, so I had to recompile the software using it with linux threads to make it working. With the old kernel these pieces worked without problems. Can it be that somehow the enlarged KVA space messed up with the threads mechanism? Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Fri, 6 Dec 2002, David Schultz wrote: Thus spake Varshavchick Alexander [EMAIL PROTECTED]: Well, now I made KVA space 2G, we'll see later on if it helps to get rid of the sudden system halts, but for some reason a side-effect has appeared: pthread_create function returns EAGAIN error now, so I had to recompile the software using it with linux threads to make it working. With the old kernel these pieces worked without problems. Can it be that somehow the enlarged KVA space messed up with the threads mechanism? I'm not a pthreads expert, but my best guess is that your program tried to create a thread with a stack address that was too high. Remember that with a 2 GB KVA, user processes have only 2 GB to play with instead of 3 GB, so attempting to mmap() a stack above about 2 GB would cause pthread_create() to return EAGAIN. Yes this makes sense, however this call to pthread_create didn't specify any special addresses for the new thread. The pthread_create was called with the NULL attribute which means that the system defaults were being used. Something in the system has gone wrong... Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Fri, 6 Dec 2002, David Schultz wrote: ... Yes this makes sense, however this call to pthread_create didn't specify any special addresses for the new thread. The pthread_create was called with the NULL attribute which means that the system defaults were being used. Something in the system has gone wrong... I just glanced at the source in -STABLE, and it appears to be a pthreads bug. (Then again, maybe I'm missing something, since nobody seems to have noticed this before.) The default address at which new thread stacks are created is just below the main stack. This address is based on the lexical constant USRSTACK, but it should be initialized in uthread_init() based on the kern.usrstack value returned by sysctl. (The correct value is already used to map the main stack's red zone.) The result is that you need to make world and recompile any apps statically linked against pthreads after building your new kernel in order to get things to work. I don't have time to fiddle with pthreads until after Christmas, but you might see if the following patch (against -STABLE) helps when you reduce the configured KVA size without remaking pthreads. ... The patch which you've suggested seems to be logical enough, yet I too cannot understand why nobody got stuck into this thing before. It means that no one in the world ever changed KVA space and used pthreads then, however real life can often be more rich than we think about it. Thank you alot, now I can estimate how this issue can influence the server, there can be nothing worse than some unknown thing which you know is living and messing things up. Now I know which software can be victim to it and what can be considered to be safe. I don't have much opportunity of fiddling with this production server, but if this issue arise again your patch will be handy. BTW will you not be sending it as a bug report with a patch already ready? Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Wed, 4 Dec 2002, Terry Lambert wrote: grep -B 7 KVA_ /sys/i386/conf/LINT -- Terry Thanks a lot Terry, and will you please correct me if I'm wrong, so I don't mess anything up on a production server? The kernel option in question is KVA_PAGES, correct? Because it's not defined in the custom server's kernel then it's value default to 256 (FreeBSD 4.5-STABLE), which makes the KVA space to occupy 1G. Then if I make KVA_PAGES=512 (KVA space 2G), will it solve the problem for this particular server having 4G of phisical memory, or must KVA_PAGES be 768 (KVA space 3G)? Have some other options to be tuned besides KVA_PAGES? Thanks again Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, Terry Lambert wrote: ... Because it's not defined in the custom server's kernel then it's value default to 256 (FreeBSD 4.5-STABLE), which makes the KVA space to occupy 1G. Then if I make KVA_PAGES=512 (KVA space 2G), will it solve the problem for this particular server having 4G of phisical memory, or must KVA_PAGES be 768 (KVA space 3G)? Have some other options to be tuned besides KVA_PAGES? IMO, KVA need to be more than half of physical memory. But I tend to use a lot of mbufs and mbuf clusters in products I work on lately (mostly networking stuff). If you don't tune kernel memory usage up, then you may be able to get away with 2G. So: 2G might be OK, 3G would be more certain, given you are cranking some things up, in the config you posted, that make me think you will be eating more physical memory. Are you talking primarily about SHMMAXPGS=262144 option here? Then may be it'll be oevrall better to reduce it and make KVA space 2G, to leave more room for user address space? You see, there cannot be any much possibility to make experiments with this server, so I very much relay on your advices, thank you again. If you follow the 1.5 rule, then you will have 6G of swap when you have 4G of physical RAM, and will definitely need to go for 3G of KVA space. No, the swap is very slightly used on this server, and the total swap size is 2G. Note, though: all space you add to KVA is subtracted from the process address space, so if you need big processes, sometimes you are better off with less physical RAM, and a larger user virtual address space. For other tuning information, see also man tuning. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, Terry Lambert wrote: IMO, KVA need to be more than half of physical memory. But I tend to use a lot of mbufs and mbuf clusters in products I work on lately (mostly networking stuff). If you don't tune kernel memory usage up, then you may be able to get away with 2G. A question arises. The value 256 (1G KVA space) acts as a default for any system installation, not depending of real phisical memory size. So for any server with RAM less than 2G (which is a majority I presume) the KVA space occupies more than half of physical memory. It can even be more than TOTAL phisical memory for servers with RAM less than 1G. Isn't it bad for a system? It seems that it is not. Then why cannot the KVA space always be made as some big value? If it is important for servers with large RAM, why it is not or a smaller servers? Can anybody besides Terry which seems to be unavailable now help? Regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Thu, 5 Dec 2002, David Schultz wrote: In FreeBSD, each process has a unique 4G virtual address space associated with it. Not every virtual page in every address space has to be associated with real memory. Most pages can be pushed out to disk when there isn't enough free RAM, and unallocated parts of the virtual address space aren't backed by anything. (Referencing an unmapped page that the system doesn't know about generally causes the program or OS to crash. You've probably seen these as ``segmentation faults'' and ``page fault in kernel mode'' panics.) To simplify things, the kernel is mapped into a fixed location in every address space. The KVA parameter controls how big a chunk the kernel gets; the remainder goes to user processes. However, only the part of the KVA reservation that the kernel actually uses is wired to physical memory. For example, if you have a 1 GB KVA reservation and the kernel allocates only 20 MB of RAM, then only 20 MB of RAM is needed (plus some epsilon if you want to be picky), but in theory, the kernel could allocate and manage up to 1 GB of data. You don't lose extra physical memory for increasing KVA, but a large KVA size does constrain the virtual address space available to user processes. Thank you David for such an excellent explanation. So if sysctl reports vm.zone_kmem_pages: 5413 vm.zone_kmem_kvaspace: 218808320 vm.kvm_size: 1065353216 vm.kvm_free: 58720256 does it mean that total KVA reservation is 1065353216 bytes (1G) and almost all of it is really mapped to physical memory because only 58720256 (56M) is free, and the server is balancing on the edge of crashing with KVA going out? Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
maxusers and random system freezes
Hi people, Can it be so that kernel maxusers=768 value being more than 512 leads to spontaneous system freezes which can take up to several hours when the system is just sleeping (only replying to ping) and doing nothing else, not allowing to telnet or anything. The system is 4.5-STABLE with much RAM (4 Gb) and the box has a heavy enough traffic so a bunch of other kernel options have been increased: options SHMMAXPGS=262144#max amount of shared mem. pages options SHMMNI=256 #max number of shared memory ident if. options SHMSEG=256 #max shared mem.segs per process options MSGSEG=32767#max num. of mes.segments in system options MSGSSZ=32 #size of msg-seg. MUST be power of 2 options MSGMNB=65535#max char. per message queue options MSGTQL=2046 #max amount of msgs in system options SEMMNU=256 #number of semaphore UNDO structures options SEMMNS=1024 #number of semaphores in system options SEMMNI=520 #number of semaphore indentifiers options SEMUME=100 #number of UNDO keys options SEMMSL=256 # max number of semaphores per id options SEMOPM=256 # max number of operations per semop call Or what else can be causing such system crashes? Any help is greatly appreciated! Regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: maxusers and random system freezes
On Wed, 4 Dec 2002, Terry Lambert wrote: Varshavchick Alexander wrote: Can it be so that kernel maxusers=768 value being more than 512 leads to spontaneous system freezes which can take up to several hours when the system is just sleeping (only replying to ping) and doing nothing else, not allowing to telnet or anything. The system is 4.5-STABLE with much RAM (4 Gb) and the box has a heavy enough traffic so a bunch of other kernel options have been increased: [ ... settings ... ] With these settings, and that much physical RAM, you should set your KVA space to 3G (the default is 2G); have you? Most likely, you are running out of KVA space for mappings. No, I didn't do it, and I'm not sure how to perform it, can you please advise? Thanks a lot! -- Terry Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
D-Link DGE-550T NIC
Hi people, did anybody use it with FreeBSD 4.5? The problem is that the system doesn't see it, however 'nge' and 'miibus' support are included into the kernel. Is it correct that it must be 'nge', because as described in the man page, only DGE-500T card is supported by nge, however both DGE-550T and DGE-500T use the same DP83820 chip. Or am I missing something here? Thanks Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
