Re: national security backdoor in FreeBSD.
Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: > In message <[EMAIL PROTECTED]>, Terry Lambert writes: > >Matthew Emmerton wrote: > >> > There is a backdoor in all versions of FreeBSD that are not compiled > >> > from source code within portmapper and telnetd. > >> > >> Hmm. Let's check out this logic. The binaries that ship on the FreeBSD > >> distros are compiled from source. When I upgrade my system, I compile from > >> source. And the backdoor only exists in binaries that are not compiled from > >> source. So where do these binaries-with-no-source come from? Oh, I know! > >> Carnivore detects FreeBSD ISO downloads, and tells the Magic Lantern > >> software on my ISP's servers to change the binaries inside the ISO images > >> that I FTP. Makes perfect sense! > > > >Bell Systems Technical Journal, July-August 1978, "On the Security > >of UNIX.", D. M. Ritchie. > > > >They hacked the compiler to hack the passwd program when it was > >being compiled, and also to hack the compiler to include hacks > >to the compiler and the passwd program when the compiler itself > >was being compiled. > > Sigh. > > Wrong reference. > > That was from Brians ACM Turning award thankyou-presentation. http://www.acm.org/classics/sep95/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.5-RELEASE generic kernel crashing on sysctl -a
Gautham Ganapathy wrote: > > Hi > > I had posted this sometime back, but didn't receive much feedback > > After installing 4.5-RELEASE, (BSD Mall Feb 2002 CD), when I ran > 'sysctl -a', the kernel crashed with the foll message. > > Fault trap 12: page fault while in kernel mode > fault virtual address = 0x6351ec0c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc02207c > stack pointer = 0x10:0xede0ebf8 > frame pointer = 0x10:0xcde0ee20 > code segment = base 0x0, limit 0xff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupts enabled, resume, IOPL = 0 > current process = 228 (sysctl) > interrupt mask = > trap number = 12 > panic : page fault > > Is this hardware related ? After I recompiled the kernel, everything I do not know much 'bout FBSD kernel, but AFAIK page fault trap is generated, if the opreating system could not swap in a page which is required by the processor. If you say, after a recompile of the kernel all went ok, it could be much helpful to the developers, if you resent this question plus an output of the original and new dmesg-output (if different) to mailto:[EMAIL PROTECTED] Jens > works fine. I saw a similar bug posted by someone around the same time, > but didn't see any replies. > > Regards > Gautham > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]> Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4.5-RELEASE generic kernel crashing on sysctl -a
Hi I had posted this sometime back, but didn't receive much feedback After installing 4.5-RELEASE, (BSD Mall Feb 2002 CD), when I ran 'sysctl -a', the kernel crashed with the foll message. Fault trap 12: page fault while in kernel mode fault virtual address = 0x6351ec0c fault code = supervisor read, page not present instruction pointer = 0x8:0xc02207c stack pointer = 0x10:0xede0ebf8 frame pointer = 0x10:0xcde0ee20 code segment = base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupts enabled, resume, IOPL = 0 current process = 228 (sysctl) interrupt mask = trap number = 12 panic : page fault Is this hardware related ? After I recompiled the kernel, everything works fine. I saw a similar bug posted by someone around the same time, but didn't see any replies. Regards Gautham To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: national security backdoor in FreeBSD.
In message <[EMAIL PROTECTED]>, Terry Lambert writes: >Matthew Emmerton wrote: >> > There is a backdoor in all versions of FreeBSD that are not compiled >> > from source code within portmapper and telnetd. >> >> Hmm. Let's check out this logic. The binaries that ship on the FreeBSD >> distros are compiled from source. When I upgrade my system, I compile from >> source. And the backdoor only exists in binaries that are not compiled from >> source. So where do these binaries-with-no-source come from? Oh, I know! >> Carnivore detects FreeBSD ISO downloads, and tells the Magic Lantern >> software on my ISP's servers to change the binaries inside the ISO images >> that I FTP. Makes perfect sense! > >Bell Systems Technical Journal, July-August 1978, "On the Security >of UNIX.", D. M. Ritchie. > >They hacked the compiler to hack the passwd program when it was >being compiled, and also to hack the compiler to include hacks >to the compiler and the passwd program when the compiler itself >was being compiled. Sigh. Wrong reference. That was from Brians ACM Turning award thankyou-presentation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: national security backdoor in FreeBSD.
Matthew Emmerton wrote: > > There is a backdoor in all versions of FreeBSD that are not compiled > > from source code within portmapper and telnetd. > > Hmm. Let's check out this logic. The binaries that ship on the FreeBSD > distros are compiled from source. When I upgrade my system, I compile from > source. And the backdoor only exists in binaries that are not compiled from > source. So where do these binaries-with-no-source come from? Oh, I know! > Carnivore detects FreeBSD ISO downloads, and tells the Magic Lantern > software on my ISP's servers to change the binaries inside the ISO images > that I FTP. Makes perfect sense! Bell Systems Technical Journal, July-August 1978, "On the Security of UNIX.", D. M. Ritchie. They hacked the compiler to hack the passwd program when it was being compiled, and also to hack the compiler to include hacks to the compiler and the passwd program when the compiler itself was being compiled. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: national security backdoor in FreeBSD.
> There is a backdoor in all versions of FreeBSD that are not compiled > from source code within portmapper and telnetd. Hmm. Let's check out this logic. The binaries that ship on the FreeBSD distros are compiled from source. When I upgrade my system, I compile from source. And the backdoor only exists in binaries that are not compiled from source. So where do these binaries-with-no-source come from? Oh, I know! Carnivore detects FreeBSD ISO downloads, and tells the Magic Lantern software on my ISP's servers to change the binaries inside the ISO images that I FTP. Makes perfect sense! -- Matt Emmerton [ A proud Canuck who takes offense to the huge Canadian flag hanging on this dude's bedroom wall. ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Distributedfolding client -- BSD Networking bug fix
The fixed version is not up yet, I will be posting it tomorrow. I have confirmed that the networking timeouts if you were having them, have been fixed. (By updating to a new version of the networking layer). Rayson Ho wrote: > > Someone on this list emailed me about a problem in the distributed > folding client a while ago... > > Howard has an updated version, can people having problems with it try > to see if it fixes the problem or not? > > Also, I don't have access to the source of the client. > > Rayson > > P.S. Here's his message: > > BSD Networking bug fix > I have a new version of the networking library which seems to have > fixed the timeouts people were experiencing on FreeBSD. Can someone > please e-mail me ([EMAIL PROTECTED]) and Ill send you the version. > Once it is confirmed that this fixes the bug (and doesnt introduce new > ones..) Ill post it on the web site officially. Thanks. > > __ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com -- -- Howard Feldman, Author of The Search for Freedom A Computer Fantasy Role-Playing Game Visit its Homepage at http://bioinfo.mshri.on.ca/people/feldman/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Distributedfolding client -- BSD Networking bug fix
Someone on this list emailed me about a problem in the distributed folding client a while ago... Howard has an updated version, can people having problems with it try to see if it fixes the problem or not? Also, I don't have access to the source of the client. Rayson P.S. Here's his message: BSD Networking bug fix I have a new version of the networking library which seems to have fixed the timeouts people were experiencing on FreeBSD. Can someone please e-mail me ([EMAIL PROTECTED]) and Ill send you the version. Once it is confirmed that this fixes the bug (and doesnt introduce new ones..) Ill post it on the web site officially. Thanks. __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP kernel freezes with nice processes.
David Gilbert wrote: > I run dnetc with an argument to run two (one for each processor). If > I realtime nice (not nasty) the processes, the computer freezes for a > few seconds every minute or two. If I have them only regular nice'd, > this does not happen. "realtime nice" = idprio? If so, probably priority inversion. Not much you can do about that without looking at the dnetc source any finding out which resources it holds locked. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
SMP kernel freezes with nice processes.
I run dnetc with an argument to run two (one for each processor). If I realtime nice (not nasty) the processes, the computer freezes for a few seconds every minute or two. If I have them only regular nice'd, this does not happen. I can make a login on the machine available if this helps. Any ideas? Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: remotely restoring over a live working system
On Wed, 15 May 2002, Dan Langille wrote: > A disk in remote 4.5-stable box started to develop bad clusters. The > hosting company replaced the drive for me. I now have a 4.5-RELEASE > system (they have 4.5-RELEASE drives as stock items). > > The defective drive is almost mounted in this box. I'm tempted to tar the > old disk over to the new disk and get everything back running that way. > It's that or upgrade to stable, install about 30 or so packages, and > manually configure everything. > > How feasible is copying from ad2 to ad0 given that I'm booting and running > off ad0? My thoughts are that it's faster but higher risk. Be careful spamming the existing files, if the tar keels over and eats, oh say, libc Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a CPU bound server
On Wed, 15 May 2002, Omar Thameen wrote: > > First off, what are the specs of the server? Cpu? Disk? Memory? Network? > > You mention it's a dual 800MHz. What kind of NIC does it have? What is the > > speed and duplex set to on it? > > Dual PIII/800 > 2G SDRAM > 2x18G IBM 10,000 rpm SCSI drives, running vinum RAID0 because I > originally thought disk accesses would be a bottleneck (but they aren't) > Tyan Thunder LE S2510 motherboard: > sym0,sym1 SCSI controller (on board, one drive on each channel) > fxp0 network (on-board), 100M, full-duplex The scsi version of the cursed board. We have lots of these laying around. > Will do. Since there's no big delivery happening at this moment, I'll > follow up later. Last I checked, it wasn't running out of mbufs > (kern.ipc.nmbufs: 34816). Can you post a netstat -m from now? It will have the peak values in it. > > qmail is also very inefficient when it comes to large delivery -- the fork > > per message and the qmail-remote trigger-hitting will eventually > > bottleneck you. It's probable you've run into it. My sympathies. :) You > > might try *dropping* concurrencyremote somewhat to reduce the > > context-switch thrash (although your context-switch numbers aren't too > > high, I've seen worse and the machine wasn't taxed too heavily). > > I've grown to this concurrencyremote fairly gradually. There was > improvement up to about 600 concurrencyremote. I added a 2nd > identical qmail queue so the deliveries wouldn't be so serial, but > didn't see anywhere near a doubling of the delivery capacity. When > only one of the queues is delivering, I see very similar vmstat > and throughput values. You've hit the limits of what the system can fork off. The solution then is to reduce the amount of forking going on. Make sure any alias files or whatever gets commonly hit on your machine avoid calling shells at all costs. Shells take a long time to start up and are slow which will slow down your throughput. It's easy to accidentally trigger shell starts if you use metacharacters in your alias files. If your mail processor can be called directly, try to arrange it so it is instead of going through an intermediary shell. > It's dnscache (~30%), then the 2 qmail-rspawn processes (~20-25% each). > I thought about running dnscache on a separate server, but don't > think that will give the performance improvement I was hoping for. I don't know much about dnscache and its characteristics, but that might be somewhere to concentrate on to get a few % cpu back. The rspawns sound about right from my experience. Moving it to a separate box, if useful, might be a good idea, at least to try. Running two qmail instances on the same machine is probably hurting each other, so you might want to collapse them back into one. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: remotely restoring over a live working system
On Wed, 15 May 2002, Dan Langille wrote: >The defective drive is almost mounted in this box. I'm tempted to tar the >old disk over to the new disk and get everything back running that way. >It's that or upgrade to stable, install about 30 or so packages, and >manually configure everything. Greetings Dan, My opinion is that catastrophe's like this are to be viewed as an opportunity to eliminate any potential bogons which might have found their way into a particular system during its service lifetime. I would upgrade this box along the security branch (RELENG_4_5) and install your 30 or so packages out of ports and start just copying the relevant config files themselves over off of the old disk (or off of your local backup copy, which I'm sure exists, right? ;-). This way you've replaced the functionality of the FreeBSD install on the old drive without copying over any of its potential quirks. It's probably adviseable to get the old system drive mounted and try to make a tar archive of it before getting rid of it completely, and keep that tarball until you're sure you've got functionality completely duplicated. Good luck. Brandon D. Valentine -- "Time to resign from the human race, wipe those tears from your lovely face. Baby, wave to the man in the ol' red caboose before all hell breaks loose." - Kinky Friedman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
remotely restoring over a live working system
A disk in remote 4.5-stable box started to develop bad clusters. The hosting company replaced the drive for me. I now have a 4.5-RELEASE system (they have 4.5-RELEASE drives as stock items). The defective drive is almost mounted in this box. I'm tempted to tar the old disk over to the new disk and get everything back running that way. It's that or upgrade to stable, install about 30 or so packages, and manually configure everything. How feasible is copying from ad2 to ad0 given that I'm booting and running off ad0? My thoughts are that it's faster but higher risk. cheers -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ - practical examples To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS Problems with Quantum Snapserver 4100 (BGE Cards!)
: :Already running the card and switch port in 100BaseTX FDX (forced) :) : :Would use GigE if the switch supported it tho Ack. Just rip the damn thing out and put in a normal 100BaseTX card, then (if you haven't already). The whole system will probably be happier. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Collect process sleeping statistics
Zhihui Zhang wrote: > What if most I/O are asynchronous writes and handled by a background > process (e.g. SoftUpdate syncer daemon or a special kernel daemon), then I > guess the wait should have something to do with memory or buffer. But I do > not know to to confirm this. Maybe some profiling or instrumentation (too > much work?) will help. Keep a count of outstanding I/O. This is your pool size. The figure of merit, according to queueing theory, is pool retention time. You can get this by having a running average of how many elelments are pending completion, vs. the frequency at which you make requests. Doing this doesn't require kernel hacks for statistics gathering. The number of tables in a McDonalds is based on pool retention time sums of the line time, the eating time, and the cleanup time. That's why, no matter how big the line is, there is always a place to sit when you get your food. For your application, this comes down to I/O latency. The bigger the latency, the more outstanding operations you need to have happening concurrently. If you are actually handling this by serializing through a daemon, then you may have to add more daemons, or speed up the ones you have. The soft updates syncer daemon can actually be sped up, but to do it, you will have to add more slots, so that placing an event into the future still works as expected (the same distance in the future). You actually probably would not benefit from this; the main bottleneck is that once a buffer is handed off, there is a effective write lock on it. So reducing the write lock overhead means reducing the period of time when the lock is active (this may not be possible to do, and still maintain the benefits of the soft updates: you will lose increasing amounts of write coelescing). Probably, you will want to tackle the problem outside the kernel, by getting the operations out of the same contention domain in the first place. Doing this is a balance, since it means that you will probably move them out of the adjacent cache space, as well, which means cache shootdowns. For a disk write cache, this could simply move the stall from the kernel down to the disk. If you are bottlenecked by physical I/O bandwidth, then, at that point, there's really nothing you can do to save yourself. If you are driving requests into the queue as fast as you can, there is also nothing you can do, except try to reduce the pool retention time itself (faster disks, enabling write caching, use of "presto-serv" type hardware, etc.). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Collect process sleeping statistics
Zhihui Zhang wrote: > Basically I have a program that does a lot of I/O and alloctes/frees a lot > of memory. The time command gives result like this: > > 6.239u 19.329s 7:59.76 5.3% 310+775k 3993+246io 7pf+0w > > I want to know why CPU is running only 5.3% of the total time. I just > want know how long it is waiting for memory and how long it is waiting for > I/O. No other process is running at the same time. You got 7 page faults with 0 waits. So it was waiting for I/O 94.7% of the time. That's statistical; the real calculation is 100% - 246/3993 = 93.8%. Generally, this comes down to a design issue that's very common in code these days, particularly code where people think "threads solve all concurrency problems". I think I should patent the correct way of solving this problem, since no one seems to use it. I'll call it "interleaved I/O"... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
"Andrew R. Reiter" wrote: > :He could also maintain a local cache of this per vnode, basically > :maintain a mirror of the lock list locally in order to see if a remote > :op must be done. > > Isn't this sorta like coda? Lock cache, not data cache. It's "sort of like": http://www.blackflag.ru/patches/nfs-client-and-server-locking-4.5-STABLE-20020312.diff -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
Alfred Perlstein wrote: > He could also maintain a local cache of this per vnode, basically > maintain a mirror of the lock list locally in order to see if a remote > op must be done. I think we are talking past each other. This is what I've been suggesting since my first message, but suggested was a political problem when going to make the necessary VOP_ADVLOCK interface changes. It's also one of the patches I put up a long time ago, and which have been updated to FreeBSD 4.5 by Andrey. He could just take Andrey's code, but if it isn't committed back to FreeBSD, he would have compatability issues. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
postfix
Do you know about performance in postfix? I have on FreeBSD (4.5) box running postfix and delivering mail in 65.000 mailboxes... I know about maildirs... but, how maildir would help me??? The postfix delivery agent simply can't do the jog. This is because a lot of entries??? help please. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Collect process sleeping statistics
What if most I/O are asynchronous writes and handled by a background process (e.g. SoftUpdate syncer daemon or a special kernel daemon), then I guess the wait should have something to do with memory or buffer. But I do not know to to confirm this. Maybe some profiling or instrumentation (too much work?) will help. -Zhihui On Wed, 15 May 2002, Alfred Perlstein wrote: > * Zhihui Zhang <[EMAIL PROTECTED]> [020515 10:33] wrote: > > > > Basically I have a program that does a lot of I/O and alloctes/frees a lot > > of memory. The time command gives result like this: > > > > 6.239u 19.329s 7:59.76 5.3% 310+775k 3993+246io 7pf+0w > > > > I want to know why CPU is running only 5.3% of the total time. I just > > want know how long it is waiting for memory and how long it is waiting for > > I/O. No other process is running at the same time. > > When not condending against other processes, almost all time not > spent on CPU is waiting for IO. > > -Alfred > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bug in pw, freebsd 4.5 [patch]
On Mon, 13 May 2002, Geoffrey C. Speicher wrote:
> On Thu, 2 May 2002, Matthew D. Fuller wrote:
>
> > I'll see if I can put some time over the next few days into delving into
> > it and at least getting the first step (of making the locking work more
> > usefully) work.
>
> Hi Matt. Just wondering if you've made any progress on making pw use a
> lockfile. Is there anything I can do to help?
OK, I'm answering my own question. Please review the two patches below
and provide feedback. They appear to work for me. Some notes:
1. The lock isn't very fine-grained. We grab one giant lock before
doing any operations at all, and let it go right before we exit.
The alternative is to lock /etc/master.passwd and /etc/group
individually, only when they're updated, but I saw no point in going
that far.
2. The lockfile is /var/run/pw.lock and it always contains the pid of
the pw process that most recently grabbed the lock.
3. The lockfile is never deleted, because doing so seemed to cause a
race condition between the time the file is closed and unlinked,
leading to password file corruption again. If anyone has a solution
to this, please speak up.
4. Should this thread be moved to -stable?
5. To test, backup your /etc/master.passwd and /etc/group, and then try
something like this, several times with the old pw to verify
consistent breakage, and then several times with the new pw to verify
that it doesn't break anymore.
# in one terminal, run this first
i=0
while [ $i -le 1000 ]; do
pw add user testuser$i
i=$(($i+1))
done
# in another terminal, wait about 10-15 seconds and then run this
# (or tail -f /etc/master.passwd and run it when testuser500 shows up)
i=0
while [ $i -le 500 ]; do
pw del user testuser$i
i=$(($i+1))
done
Geoff
--- pwupd.h.origTue May 14 22:06:37 2002
+++ pwupd.h Wed May 15 13:35:14 2002
@@ -110,6 +110,12 @@
#ifndef _GROUP
#define _GROUP "group"
#endif
+#ifndef _PWLOCK
+#define _PWLOCK"/var/run/pw.lock"
+#endif
+#ifndef _LOCK_FILE_MODE
+#define _LOCK_FILE_MODE(S_IRUSR | S_IWUSR)
+#endif
__BEGIN_DECLS
int addpwent __P((struct passwd * pwd));
--- pw.c.orig Wed May 15 13:35:21 2002
+++ pw.cWed May 15 13:37:53 2002
@@ -98,10 +98,12 @@
main(int argc, char *argv[])
{
int ch;
+ int lockfd;
int mode = -1;
int which = -1;
char*config = NULL;
struct userconf *cnf;
+ char*pidstr;
static const char *opts[W_NUM][M_NUM] =
{
@@ -202,6 +204,17 @@
errx(EX_NOPERM, "you must be root to run this program");
/*
+* Gain exclusive lock before updating any files
+*/
+ lockfd = open(_PWLOCK, O_WRONLY | O_CREAT | O_EXLOCK,
_LOCK_FILE_MODE);
+ if (lockfd == -1)
+ err(EX_UNAVAILABLE, "%s", _PWLOCK);
+
+ ftruncate(lockfd,0);
+ write(lockfd, pidstr, asprintf(&pidstr, "%d", getpid()));
+ free(pidstr);
+
+ /*
* We should immediately look for the -q 'quiet' switch so that we
* don't bother with extraneous errors
*/
@@ -226,7 +239,7 @@
setgrdir(etcpath);
}
}
-
+
/*
* Now, let's do the common initialisation
*/
@@ -259,6 +272,12 @@
pw_log(cnf, mode, which, "NIS maps
updated");
}
}
+
+ /*
+* Release the lock
+*/
+ close(lockfd);
+
return ch;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Collect process sleeping statistics
* Zhihui Zhang <[EMAIL PROTECTED]> [020515 10:33] wrote: > > Basically I have a program that does a lot of I/O and alloctes/frees a lot > of memory. The time command gives result like this: > > 6.239u 19.329s 7:59.76 5.3% 310+775k 3993+246io 7pf+0w > > I want to know why CPU is running only 5.3% of the total time. I just > want know how long it is waiting for memory and how long it is waiting for > I/O. No other process is running at the same time. When not condending against other processes, almost all time not spent on CPU is waiting for IO. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
On Tue, 14 May 2002, Terry Lambert wrote:
> Richard Sharpe wrote:
> > Hmmm, I wasn't very clear ...
> >
> > What I am proposing is a 'simple' fix that simply changes
> >
> > p->p_flag |= P_ADVLOCK;
> >
> > to
> >
> > fp->l_flag |= P_ADVLOCK;
> >
> > And never resets it, and then in closef,
> >
> > if ((fp->l_flag & P_ADVLOCK) && fp->f_type == DTYPE_VNODE) {
> > lf.l_whence = SEEK_SET;
> > lf.l_start = 0;
> > lf.l_len = 0;
> > lf.l_type = F_UNLCK;
> > vp = (struct vnode *)fp->f_data;
> > (void) VOP_ADVLOCK(vp, (caddr_t)p->p_leader, F_UNLCK, &lf,
> > F_POSIX);
> > }
> >
> > Which still means that the correct functionality is implemented, but we
> > only try to unlock files that have ever been locked before, or where we
> > are sharing a file struct with another (related) process and one of them
> > has locked the file.
>
> Do you expect to share the same "fp" between multiple open
> instances for a given file within a single process?
>
> I think your approach will fail to implement proper POSIX
> file locking semantics.
>
> I really hate POSIX semantics, but you have to implement
> them exactly (at least by default), because programs are
> written to expect them.
>
> Basically, this means that if you open a file twice, lock it
> via the first fd, then close the second fd, all locks are
> released. In your code, it looks like what would happen is
> that when you closed the second fd, the fp->l_flag won't have
> the bit set. Correct me if I'm wrong?
>
> The reason for the extra overhead now is that you can't do
> this on an open instance basis because of POSIX, so it does it
> on a process instance basis.
OK, you have convinced me. I have looked at the POSIX spec in this area,
and agree that I can't do what I want to do.
> The only other alternative is to do it on a vp basis -- and
> since multiple fp's can point to the same vp, your option #2
> will fail, as described above, but my suggestion to do the
> locking locally will associate it the the vp (or the v_data,
> depending on which version of FreeBSD, and where the VOP_ADVLOCK
> hangs the lock list off of: the vnode or the inode) will
> maintain the proper semantics.
>
> Your intent isn't really to avoid the VOP_ADVLOCK call, it's
> to avoid making an RPC call to satisfy the VOP_ADVLOCK call,
> right?
Yes, correct. We will have to do it in the vnode layer as you suggest.
Currently we are using 4.3 and moving to 4.5, so we will have to figure
out the differences.
> You can't really avoid *all* the "avoidable overhead", without
> restructuring the VOP_ADVLOCK interface, which is politically
> difficult.
I wouldn't want to try. Too much code to change and too much chance of a
massive screw-up.
Thanks for perservering with me.
Regards
-
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Collect process sleeping statistics
Basically I have a program that does a lot of I/O and alloctes/frees a lot of memory. The time command gives result like this: 6.239u 19.329s 7:59.76 5.3% 310+775k 3993+246io 7pf+0w I want to know why CPU is running only 5.3% of the total time. I just want know how long it is waiting for memory and how long it is waiting for I/O. No other process is running at the same time. -Zhihui On Tue, 14 May 2002, Terry Lambert wrote: > Doug White wrote: > > On Mon, 13 May 2002, Zhihui Zhang wrote: > > > A process can sleep for various reasons such as memory, I/O etc. Is there > > > a way to collect statistics about how long it sleeps for different > > > reasons? Thanks. > > > > I don't think it's actually accounted for anywhere, but if a process does > > go to sleep the WCHAN will be filled in and visible in top and ps. > > > > You could write a program to collect the WCHANs every so often and build > > some course stats. And if you really wanted to get fancy it might not be > > too hard to build a scheduler or hz-driven procedure to log them directly > > in the kernel. > > Profiling will also show the amount of time spent in "sleep" for > a process. Generally, you eliminate these arc's as "unrecoverable > system overhead". You typically "treat" these symptoms by changing > algorithms in user space, or, if you have an application specific > need, hacking the kernel after doing kernel profiling on the code > paths. > > I don't think a statistical sampling of the wait channels outstanding > would be very useful. Statistical sampling done for normal profiling > (profiling without compiler hacks for recording function entry and > exit) is barely generally useful on its own (IMO); you would effectively > have to hook into the profiling clock, which means kernel space work, > for "outstanding wait channel" tagging. > > The reason it wouldn't be that useful is that profiling arcs are > generally either above or below -- not spanning -- the user/kernel > boundary, so there's a lot of information that would get lost in > the process, I think. > > -- Terry > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
* Andrew R. Reiter <[EMAIL PROTECTED]> [020515 09:54] wrote: > On Wed, 15 May 2002, Alfred Perlstein wrote: > > :* Terry Lambert <[EMAIL PROTECTED]> [020515 01:36] wrote: > :> Alfred Perlstein wrote: > :> > As Terry stated you can't do that, however you could cache that the > :> > VNODE has a lock, that would reduce the requirement for calling the > :> > ADVLOCK VOP. > :> You'd really have to know when the lock list went to NULL, to get > :> any benefit out of it, since locking would still end up being per-file > :> sticky. You could post-check after every successful unlock... but to > :> cache the remote state would mean another RPC to ask for locks, which > :> would just be front-loading the expense, instead of back-loading it. > : > :[snip] > : > :He could also maintain a local cache of this per vnode, basically > :maintain a mirror of the lock list locally in order to see if a remote > :op must be done. > > Isn't this sorta like coda? I'm not a coda expert so I wouldn't know, but I wasn't professing to have invented something profound by suggesting a client cache. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
On Wed, 15 May 2002, Alfred Perlstein wrote: :* Terry Lambert <[EMAIL PROTECTED]> [020515 01:36] wrote: :> Alfred Perlstein wrote: :> > As Terry stated you can't do that, however you could cache that the :> > VNODE has a lock, that would reduce the requirement for calling the :> > ADVLOCK VOP. :> You'd really have to know when the lock list went to NULL, to get :> any benefit out of it, since locking would still end up being per-file :> sticky. You could post-check after every successful unlock... but to :> cache the remote state would mean another RPC to ask for locks, which :> would just be front-loading the expense, instead of back-loading it. : :[snip] : :He could also maintain a local cache of this per vnode, basically :maintain a mirror of the lock list locally in order to see if a remote :op must be done. Isn't this sorta like coda? -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
* Terry Lambert <[EMAIL PROTECTED]> [020515 01:36] wrote: > Alfred Perlstein wrote: > > As Terry stated you can't do that, however you could cache that the > > VNODE has a lock, that would reduce the requirement for calling the > > ADVLOCK VOP. > You'd really have to know when the lock list went to NULL, to get > any benefit out of it, since locking would still end up being per-file > sticky. You could post-check after every successful unlock... but to > cache the remote state would mean another RPC to ask for locks, which > would just be front-loading the expense, instead of back-loading it. [snip] He could also maintain a local cache of this per vnode, basically maintain a mirror of the lock list locally in order to see if a remote op must be done. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problem with sysctl() and HW_PHYSMEM
A thousand pardons for the duplicate post - forgot the subject on the
original!!
---
All,
I have a need to be able to determine the amount of physical
memory in
a machine. Looking at the man page for sysctl(), that seems to be the
answer, but it behaves a oddly in that it doesn't return what I feel is
the actual amount of RAM in the machine. It appears to be taking some
memory off the top (for kernel structures?), and not actually reporting
the physical memory.
Here's my example:
#include
#include
#include
int main ()
{
int mib[2], realmem;
size_t len;
mib[0] = CTL_HW;
mib[1] = HW_PHYSMEM;
len = sizeof(realmem);
sysctl(mib,2,(void *) &realmem, (void *) &len,NULL,0);
printf ("%d bytes\n\n", realmem);
}
On the machine that I'm using, this is returning 534564864, which, when
divided by (1024 * 1024), returns 509. The machine has 512MB in it, so
it's losing 3MB somewhere. It's more of an annoyance than anything, but
I need to be able to report this number accurately regardless of the
machine it's on. Losing memory to kernel or what have you is not
consistent with this reporting physical memory.
The machine I'm running is running 4.4-RELEASE, with 512MB RAM. Can
anyone point me in the direction of where I may be going wrong?
Many thanks,
Rich
--
Rich Haney
Senior Operations Tools Developer
NTT/VERIO
561-999-8339
Lubarsky's Law of Cybernetic Entomology:
There's always one more bug.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[no subject]
All,
I have a need to be able to determine the amount of physical
memory in
a machine. Looking at the man page for sysctl(), that seems to be the
answer, but it behaves a oddly in that it doesn't return what I feel is
the actual amount of RAM in the machine. It appears to be taking some
memory off the top (for kernel structures?), and not actually reporting
the physical memory.
Here's my example:
#include
#include
#include
int main ()
{
int mib[2], realmem;
size_t len;
mib[0] = CTL_HW;
mib[1] = HW_PHYSMEM;
len = sizeof(realmem);
sysctl(mib,2,(void *) &realmem, (void *) &len,NULL,0);
printf ("%d bytes\n\n", realmem);
}
On the machine that I'm using, this is returning 534564864, which, when
divided by (1024 * 1024), returns 509. The machine has 512MB in it, so
it's losing 3MB somewhere. It's more of an annoyance than anything, but
I need to be able to report this number accurately regardless of the
machine it's on. Losing memory to kernel or what have you is not
consistent with this reporting physical memory.
The machine I'm running is running 4.4-RELEASE, with 512MB RAM. Can
anyone point me in the direction of where I may be going wrong?
Many thanks,
Rich
--
Rich Haney
Senior Operations Tools Developer
NTT/VERIO
561-999-8339
Lubarsky's Law of Cybernetic Entomology:
There's always one more bug.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Verba Volant
The following email address, "[EMAIL PROTECTED]" has been removed from the Verba Volant Newsletter list. If you did not cancel your email address or you wish to continue receiving Verba Volant, please send an e-mail to [EMAIL PROTECTED] Thank you and best regards, Verba Volant To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS Problems with Quantum Snapserver 4100 (BGE Cards!)
Already running the card and switch port in 100BaseTX FDX (forced) :) Would use GigE if the switch supported it tho Thus spake Matthew Dillon ([EMAIL PROTECTED]) : > It should also work if you force the GigE card into 100BaseTX mode, > assuming the switch can deal with it. Though of course then you are > not getting GigE speeds. > > Your description is very similar to a problem I had on my 2550's that > Bill Paul finally solved. It turned out that my 2550's (BCM5700) were > not initializing the polynomial functions properly and this resulted > in packet loss. Whenever you get bit stuffing packet loss like that, > certain bit patterns will *always* fail. But I'm sure this issue has > already been dealt with on the 5701 so the problem you are having is > probably different. > > The result is the appearance of hicups and delays on a TCP connection, > and repeatable hangs when just the wrong data pattern is transmitted > (because that packet winds up failing every time rather then just some > of the time). > > Another possibility in regards to packet loss is simply a bad cable > (if you are running GigE over copper). GigE is very sensitive to cable > issues and a bad crimp will screw things up easily. > > In anycase, my feeling about GigE in general is that it's a great cheap > way to aggregate data on an uplink, or to an NFS server that needs it, > but the incremental cost and hassle factor are still too high to > extend the benefit to generic servers. > > -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: laptop's modem
Wilko Bulte wrote: > > Do you mean "ltmdm", the Lucent Winmodem driver? > > Correct. [ ... ] > Win2K calls it a LT Win Modem. Definitely a Lucent. > > Did your E700 work with -STABLE? The "ltmdm" thing didn't work > > with some Lucent modems, in the same way the binary only Olicomm > > driver wroked with HSF, identified HCF as a modem, but then did > > not work with it. I'm pretty sure it's still lying about finding > > some modems (but maybe not yours; dpends on your experience with > > -stable). > > I only found out about ltmdm after I went to -current so I don't know. Could still be a recognition problem. FWIW, the following may help: http://www.close.u-net.com/ltmodem.html http://www.tantalophile.demon.co.uk/linmodem/jamie/ ...yeah... I accumulated a *lot* of bookmarks trying to get my frigging modem working. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: laptop's modem
On Wed, May 15, 2002 at 02:11:10AM -0700, Terry Lambert wrote: > Wilko Bulte wrote: > > On Wed, May 15, 2002 at 01:50:45AM -0700, Terry Lambert wrote: > > > Dmitry Shupilov wrote: > > > > Sorry for non-topic question but HELP me! > > > > I got laptop Compaq Armada m700 with internal modem Compaq 56K mini > > > > PCI. After the new install FreeBSD on laptop I cannot dial out - > > > > system doesn't see the modem. What should I do or where can I find > > > > some info about it? (On windozz it works on COM4, so I try to trick > > > > with device sioX but it didn't help). > > > > > > If it's a Rockwell HCF or HSF, there are now Linux drivers whose > > > source code can be downloaded from the Rockwell web site. From > > > a casual look at them, they seem that they would be pretty easy > > > to port to FreeBSD. > > > > My E700 (I think it has the same mainboard) has the modem recognised > > by the ltmodem (see the ports collection). Unfortunately it does not seem > > to get a /dev entry in devfs (my E700 runs -current). > > Do you mean "ltmdm", the Lucent Winmodem driver? Correct. > I'm not sure it's the same modem; generally the modems are on a > little daughter card that's pinned out the same for a lot of the > different manufacturers (sometimes by the PC vendor), so that they > can switch vendors. Last Compaq I looked at has a Rockwell (guess > it's "Conexant" now) HCF... just like my Sony. On the E700 it tells me (well, told me, -current no longer is compatible with the ltmdm port :( ) it found a Lucent. Win2K calls it a LT Win Modem. > The HCF modems are really cheap little buggers; unlike the HSF, > they lack even more on-board intelligence (just when you though > winmodems couldn't get any stupider). Never underestimate M$ aimed hardware ;-) > Did your E700 work with -STABLE? The "ltmdm" thing didn't work > with some Lucent modems, in the same way the binary only Olicomm > driver wroked with HSF, identified HCF as a modem, but then did > not work with it. I'm pretty sure it's still lying about finding > some modems (but maybe not yours; dpends on your experience with > -stable). I only found out about ltmdm after I went to -current so I don't know. > I *hate* winmodems. 8-(. Yes, I agree. ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: laptop's modem
Wilko Bulte wrote: > On Wed, May 15, 2002 at 01:50:45AM -0700, Terry Lambert wrote: > > Dmitry Shupilov wrote: > > > Sorry for non-topic question but HELP me! > > > I got laptop Compaq Armada m700 with internal modem Compaq 56K mini > > > PCI. After the new install FreeBSD on laptop I cannot dial out - > > > system doesn't see the modem. What should I do or where can I find > > > some info about it? (On windozz it works on COM4, so I try to trick > > > with device sioX but it didn't help). > > > > If it's a Rockwell HCF or HSF, there are now Linux drivers whose > > source code can be downloaded from the Rockwell web site. From > > a casual look at them, they seem that they would be pretty easy > > to port to FreeBSD. > > My E700 (I think it has the same mainboard) has the modem recognised > by the ltmodem (see the ports collection). Unfortunately it does not seem > to get a /dev entry in devfs (my E700 runs -current). Do you mean "ltmdm", the Lucent Winmodem driver? I'm not sure it's the same modem; generally the modems are on a little daughter card that's pinned out the same for a lot of the different manufacturers (sometimes by the PC vendor), so that they can switch vendors. Last Compaq I looked at has a Rockwell (guess it's "Conexant" now) HCF... just like my Sony. The HCF modems are really cheap little buggers; unlike the HSF, they lack even more on-board intelligence (just when you though winmodems couldn't get any stupider). Did your E700 work with -STABLE? The "ltmdm" thing didn't work with some Lucent modems, in the same way the binary only Olicomm driver wroked with HSF, identified HCF as a modem, but then did not work with it. I'm pretty sure it's still lying about finding some modems (but maybe not yours; dpends on your experience with -stable). I *hate* winmodems. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: laptop's modem
On Wed, May 15, 2002 at 01:50:45AM -0700, Terry Lambert wrote: > Dmitry Shupilov wrote: > > Sorry for non-topic question but HELP me! > > I got laptop Compaq Armada m700 with internal modem Compaq 56K mini > > PCI. After the new install FreeBSD on laptop I cannot dial out - > > system doesn't see the modem. What should I do or where can I find > > some info about it? (On windozz it works on COM4, so I try to trick > > with device sioX but it didn't help). > > If it's a Rockwell HCF or HSF, there are now Linux drivers whose > source code can be downloaded from the Rockwell web site. From > a casual look at them, they seem that they would be pretty easy > to port to FreeBSD. My E700 (I think it has the same mainboard) has the modem recognised by the ltmodem (see the ports collection). Unfortunately it does not seem to get a /dev entry in devfs (my E700 runs -current). Wilko -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: laptop's modem
Dmitry Shupilov wrote: > Sorry for non-topic question but HELP me! > I got laptop Compaq Armada m700 with internal modem Compaq 56K mini > PCI. After the new install FreeBSD on laptop I cannot dial out - > system doesn't see the modem. What should I do or where can I find > some info about it? (On windozz it works on COM4, so I try to trick > with device sioX but it didn't help). If it's a Rockwell HCF or HSF, there are now Linux drivers whose source code can be downloaded from the Rockwell web site. From a casual look at them, they seem that they would be pretty easy to port to FreeBSD. I will probably port the HCF driver before next Christmas, if no one else gets around to it, or earlier, if I end up being paid to travel, just to avoid dragging around my external modem for my Sony VAIO. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SIGPOLL
Eugene Panchenko wrote: > SysV defines SIGPOLL, as well as Linux, Solaris, and (IIRC) Irix. > However, it is NOT defined in any of *BSD. In Linux it is > simple "#define SIGPOLL SIGIO". Some apps need it, thought. What are > the general policy for this: keep as *BSD and patch every SIGPOLL-app > accordingly, or modify sys/signal.h ? make -DSIGPOLL=SIGIO ? Personally, I'd prefer that the code be properly ported to BSD, but that's just me. PS: Apps that rely on SIGPOLL are usually inherently broken, since programmers who depend on SIGPOLL generally expect it to be an even, rather than a persistant condition, and as we all know, signals are persistant conditions, not events. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File locking, closes and performance in a distributed filesystemenv
Alfred Perlstein wrote: > As Terry stated you can't do that, however you could cache that the > VNODE has a lock, that would reduce the requirement for calling the > ADVLOCK VOP. You'd really have to know when the lock list went to NULL, to get any benefit out of it, since locking would still end up being per-file sticky. You could post-check after every successful unlock... but to cache the remote state would mean another RPC to ask for locks, which would just be front-loading the expense, instead of back-loading it. I don't think this would be a win: applications don't really choose selective locking: either they tend to lock everything or they don't respect locking at all. Also, it's very common to check a lock before doing something, so you'll still have all that unnecessary traffic. You really need to cache the entire local lock list. The most reasonable way to so this would be for a "magic" return value from the lock primitive. But since you can't get cooperation from the other end on that, the only reasonable way is to maintain the lock list locally as well as remotely, and then do a check for NULL (instead of the flag) before attempting to proxy the unnecessary unlock request. Which is basically what I said the first time. 8-). I suspect there are other things he's not telling us, too, like session handoff or other clustering protocols, which means that you could have your locks handed off, and end up without the "there's a lock" flag set, in any case, so there's still room to shoot your foot off. This may be an incorrect suspicion, but... generally, distributed file systems are built that way for a particular reason/application set, which includes things like client virtualization/migration/handoff. Too fun. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: laptop's modem
On Wed, 2002-05-15 at 16:23, Dmitry Shupilov wrote: > system doesn't see the modem. What should I do or where can I find > some info about it? (On windozz it works on COM4, so I try to trick > with device sioX but it didn't help). It's almost certainly a Win modem. I don't believe there are any drivers for the 3com win-modem so your only option is to buy a real PCMCIA modem. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a CPU bound server
On Tue, May 14, 2002 at 09:25:21PM -0700, Doug White wrote: > Mmm, mail server tuning, something I have some experience in :-) Just what I was hoping to hear! > First off, what are the specs of the server? Cpu? Disk? Memory? Network? > You mention it's a dual 800MHz. What kind of NIC does it have? What is the > speed and duplex set to on it? Dual PIII/800 2G SDRAM 2x18G IBM 10,000 rpm SCSI drives, running vinum RAID0 because I originally thought disk accesses would be a bottleneck (but they aren't) Tyan Thunder LE S2510 motherboard: sym0,sym1 SCSI controller (on board, one drive on each channel) fxp0 network (on-board), 100M, full-duplex > Secondly, what period was your vmstat run over? The vmstat shows most of > the time spent in system. I'm thinking it might be network-based but > without the specs its hard to tell. Updating every second. It has about the same network I/O as the heavily hit webserver (same # of interrupts/second), but smtp is a lengthier negotiation, right? > While you're getting specs run netstat -m every so often and collect the > mbuf and mbuf cluster utilization numbers. Will do. Since there's no big delivery happening at this moment, I'll follow up later. Last I checked, it wasn't running out of mbufs (kern.ipc.nmbufs: 34816). > qmail is also very inefficient when it comes to large delivery -- the fork > per message and the qmail-remote trigger-hitting will eventually > bottleneck you. It's probable you've run into it. My sympathies. :) You > might try *dropping* concurrencyremote somewhat to reduce the > context-switch thrash (although your context-switch numbers aren't too > high, I've seen worse and the machine wasn't taxed too heavily). I've grown to this concurrencyremote fairly gradually. There was improvement up to about 600 concurrencyremote. I added a 2nd identical qmail queue so the deliveries wouldn't be so serial, but didn't see anywhere near a doubling of the delivery capacity. When only one of the queues is delivering, I see very similar vmstat and throughput values. > It might be interesting to run top and find what the major culprit of cpu > usage is. Somehow I think it'll be qmail-send. It's dnscache (~30%), then the 2 qmail-rspawn processes (~20-25% each). I thought about running dnscache on a separate server, but don't think that will give the performance improvement I was hoping for. Omar > On Tue, 14 May 2002, Omar Thameen wrote: > > > I've got a pretty heavily loaded server which is doing mostly > > mailing list delivery. It happens to be running qmail with a large > > number of concurrencyremotes (about 1000), meaning that there is > > one smtp delivery process spawned for each message. I've hit a > > plateau with regards to the amount of bandwidth that the server > > can push out - I see similar performance with half the concurrencyremotes. > > > > As best as I can tell, the server is CPU bound. My main question > > is whether there are any kernel parameters I can tune to improve > > performance, or whether I just need to get more powerful processors > > (Xeons?). The current system is a dual PIII/800. [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
