Re: Machines are getting too damn fast
Aloha! (Sorry for jumping right in to the thread here...) This might be a good time to mention the STREAM benchmark developed by John McCalpin. It measures sustained bandwidth of systems. The official web page is at: http://www.cs.virginia.edu/stream/ If you check the section under "PC-compatible Results" you should find machines comparable to what you are measuring. Also, there are a tool out there that will measure effective latency for cache levels and main store for a system - both first page and burst transfers. Need to search my ever inflating bookmarks... The news group comp.arch might be a source of info and would probably be interested in your results too. Matt Dillon wrote: :You should see what speed RamBus they were using, 600 or 800 Mhz. It is :pretty fast for large memory writes and reads. It'd be cool to see how :the different speeds stack up against one another. DDR comparisons would :be cool too. Yeah, for the frequency, you have to take into account that :these are different chips than your PIII or Athlons and the performance :difference is not simply a linear relation to the frequency rating :(i.e.: 1.3Ghz is not really over one-billion instructions per second, :just clocks per second). We installed Linux at a UC Free OS User Group :installfest here in cincinnati, it was pretty sweet. The machine was a :Dell and the case was freakin' huge. It also came with a 21" monitor and :stuff. The performace was really good, but not really any better than I :hads gleaned from the newer 1Ghz Athlons or PIII's. It says 800 MHz (PC-800 RIMMs) on the side of the box. The technical reviews basically say that bulk transfer rates for RamBus blow DDR away, but DDR wins for random reads and writes due to RamBus's higher startup latency. I don't have any DDR systems to test but I can devise a test program. Celeron 650 MHz (HP desktop) (DIMM) 16.16 MBytes/sec (copy) Pentium III 550 MHz (Dell 2400) (DIMM) 25.90 MBytes/sec (copy) Pentium 4 1.3 GHz / PC-800 RIMMs (Sony VAIO) 32.38 MBytes/sec (copy) -Matt -- Cheers! Joachim - Alltid i harmonisk svngning --- FairLight -- FairLight -- FairLight -- FairLight --- Joachim Strmbergson ASIC SoC designer, nice to CUTE animals Phone: +46(0)31 - 27 98 47Web: http://www.ludd.luth.se/~watchman --- Spamfodder: [EMAIL PROTECTED] --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
I believe DDR still has it bead (PC2100 that is), Rambus serailizes all writes
to 32 bit or 16 bit (an even 8 bit) depending on the modules. I haven't seen any
64bit RIMMs. Also, DDR scales higher (up to 333Mhz I think). Just wait for
that. I've pretty much given up on RamBus, I saw back in '96 when they talked
about how great it would be. I thought it was crap back then. The idea is that
it can queue 28 mem ops, where SDRAM can only do like 4. Typical environments
typically don't do the writes that it looks good on, jsut certain special cases.
That's where you get into the fact that RamBus sucks for use in PCs. Too
specialized. Too proprietary.
Matt Dillon had the audacity to say:
:You should see what speed RamBus they were using, 600 or 800 Mhz. It is
:pretty fast for large memory writes and reads. It'd be cool to see how
:the different speeds stack up against one another. DDR comparisons would
:be cool too. Yeah, for the frequency, you have to take into account that
:these are different chips than your PIII or Athlons and the performance
:difference is not simply a linear relation to the frequency rating
:(i.e.: 1.3Ghz is not really over one-billion instructions per second,
:just clocks per second). We installed Linux at a UC Free OS User Group
:installfest here in cincinnati, it was pretty sweet. The machine was a
:Dell and the case was freakin' huge. It also came with a 21" monitor and
:stuff. The performace was really good, but not really any better than I
:hads gleaned from the newer 1Ghz Athlons or PIII's.
It says 800 MHz (PC-800 RIMMs) on the side of the box.
The technical reviews basically say that bulk transfer rates for
RamBus blow DDR away, but DDR wins for random reads and writes
due to RamBus's higher startup latency. I don't have any DDR
systems to test but I can devise a test program.
Celeron 650 MHz (HP desktop) (DIMM)
16.16 MBytes/sec (copy)
Pentium III 550 MHz (Dell 2400) (DIMM)
25.90 MBytes/sec (copy)
Pentium 4 1.3 GHz / PC-800 RIMMs (Sony VAIO)
32.38 MBytes/sec (copy)
-Matt
Compile -O2, changing the two occurances of '512' to '4' will reproduce
the original bulk-transfer rates. By default this program tests
single-transfer (always cache miss).
#include sys/types.h
#include sys/time.h
#include stdio.h
#include stdlib.h
#include stdarg.h
#include unistd.h
#define NLOOP 100
char Buf1[2 * 1024 * 1024];
char Buf2[2 * 1024 * 1024];
int deltausecs(struct timeval *tv1, struct timeval *tv2);
int
main(int ac, char **av)
{
int i;
double dtime;
struct timeval tv1;
struct timeval tv2;
memset(Buf1, 1, sizeof(Buf1));
for (i = 0; i 10; ++i)
bcopy(Buf1, Buf2, sizeof(Buf1));
gettimeofday(tv1, NULL);
for (i = 0; i NLOOP; ++i) {
int j;
int k;
for (k = sizeof(int); k = 512; k += sizeof(int)) {
for (j = sizeof(Buf1) - k; j = 0; j -= 512)
*(int *)(Buf2 + j) = *(int *)(Buf1 + j);
}
}
gettimeofday(tv2, NULL);
dtime = (double)deltausecs(tv1, tv2);
printf("%6.2f MBytes/sec (copy)\n", (double)sizeof(Buf1) * NLOOP / dtime);
return(0);
}
int
deltausecs(struct timeval *tv1, struct timeval *tv2)
{
int usec;
usec = (tv2-tv_usec + 100 - tv1-tv_usec);
usec += (tv2-tv_sec - tv1-tv_sec - 1) * 100;
return(usec);
}
PGP signature
Re: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
On Mon, Mar 05, 2001 at 03:18:35AM -0800, Mark Murray wrote: markm 2001/03/05 03:18:35 PST Modified files: kerberos5/usr.binMakefile Added files: kerberos5/usr.bin/k5su Makefile Log: *Sigh*. What I did without this, I have no idea. Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. Curious, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: easy way to crash freebsd
Hello, I found a bit more ecsotic way to do this: - put your fdd to a piece of paper to make it roll a bit slower - mount floppy and initiate some write operation - regulating the preassure to the device you can achive the effect (I/O err., autom. reboot in progress :P) On Fri, 2 Mar 2001, Dan Phoenix wrote: symbolic link /etc/resolv.conf to a non-existant filethrow a bunch of connections at it and watch it reboot. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED]| | make installworld| | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +__+ 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: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
"Jacques A. Vidrine" [EMAIL PROTECTED] writes: Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. Yes. My current plan of things to happen (in -current and after 4.3) is to ditch the v4 programs basically and install the v5 ones under the canonical names (with v4-compatibility if compiled in). And to always build and install the krb5 programs/libraries, but ifdef'ing the support in other programs. How does that sounds? /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
On Mon, 5 Mar 2001, E.B. Dreger wrote: Date: Sun, 04 Mar 2001 19:39:09 -0600 From: David A. Gobeille [EMAIL PROTECTED] It would also be interesting to see the numbers for an Athlon/PIII system with DDR, if anyone has such a machine. Personally, I'd be [more] interested in a ServerWorks III HE core chipset with four-way interleaved SDRAM. :-) I've got a ServerWorks III HE-SL system with 512MB of two-way interleaved PC133 SDRAM and dual PIII-800's. Is that close enough? :-) Here is my "memory bandwidth test", much much simpler and less scientific than Matt's: dd if=/dev/zero of=/dev/null bs=10m count=1000 1000+0 records in 1000+0 records out 1048576 bytes transferred in 23.716504 secs (442129245 bytes/sec) I just did a recent 4.2-STABLE 'make -j 4 buildworld' on that system in just over 34 minutes. Here's the time output: 1980.707u 768.223s 34:20.89 133.3% 1297+1456k 39517+6202io 1661pf+0w If one _truly_ needs the bandwidth of Rambus (which, IIRC, is higher real-world latency than SDRAM), then how about having the bus bandwidth to back it up? The higher real-world latency of RDRAM over SDRAM is what makes the benefits of its higher bandwidth so questionable. PC2100 DDR-SDRAM -- which has higher latencies than regular SDRAM but still lower than RDRAM -- should have it beat soundly, though we'll have to wait for some systems that are actually designed to take advantage of it to say for sure. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. When all the K5 utils reliably double-up as K4 ones, I'll fix this. (I think we are really close, BTW). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
"Jacques A. Vidrine" [EMAIL PROTECTED] writes: Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. Yes. My current plan of things to happen (in -current and after 4.3) is to ditch the v4 programs basically and install the v5 ones under the canonical names (with v4-compatibility if compiled in). And to always build and install the krb5 programs/libraries, but ifdef'ing the support in other programs. How does that sounds? Wonderful! If you need repo-copying done, I'm your man! -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Missing support in FreeBSD for large file sizes?
According to the "Maxtor picks Windows, dumps open source" article at http://news.cnet.com/news/0-1003-200-5009496.html?tag=lh FreeBSD "did not support large file sizes, Macintosh and newer Novell file systems, or backup and management software from companies such as OpenView, Tivoli and Microsoft". Now I can understand what they say about missing Tivoli support - we're using Tivoli backup here ourselves, and the SCO ADSM/TSM client that we currently use to backup FreeBSD is passable, but nothing more. A native FreeBSD client would be much preferable. What I can't understand is the reference to missing support for large file sizes - as far as I know, that's one of FreeBSD's strengths! Anybody care to guess what they mean here? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: easy way to crash freebsd
At 15:25 02/03/01 -0800, Alfred Perlstein wrote: On Fri, 2 Mar 2001, Dan Phoenix wrote: symbolic link /etc/resolv.conf to a non-existant filethrow a bunch of connections at it and watch it reboot. * Dan Phoenix [EMAIL PROTECTED] [010302 15:24] wrote: People asking me how this could be used as a local user. Well i guess if you wanted to you could find something root runs that writes to /tmp then umask resolv.conf and echo "" resolv.conf I am in no way supporting that...just answering a question. Try overwriting /dev/mem, it's much more interesting. There are a lot of other ways: - reboot - halt ... and the simplest of all: turn off the ON/OFF button. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing support in FreeBSD for large file sizes?
Very annoying. And Maxtor also missed that Networker is available for FreeBSD as well. According to the "Maxtor picks Windows, dumps open source" article at http://news.cnet.com/news/0-1003-200-5009496.html?tag=lh FreeBSD "did not support large file sizes, Macintosh and newer Novell file systems, or backup and management software from companies such as OpenView, Tivoli and Microsoft". Now I can understand what they say about missing Tivoli support - we're using Tivoli backup here ourselves, and the SCO ADSM/TSM client that we currently use to backup FreeBSD is passable, but nothing more. A native FreeBSD client would be much preferable. What I can't understand is the reference to missing support for large file sizes - as far as I know, that's one of FreeBSD's strengths! Anybody care to guess what they mean here? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] 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: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5suMakefile
BTW, is this still valid? From /etc/defaults/make.conf: # Kerberos 5 # If you want KerberosIV (KTH Heimdal), define this: # ** WARNING ** # ** WARNING ** This is very experimental at this stage. If you # ** WARNING ** need stable Kerberos5, rather use the port(s). # ** WARNING ** # #MAKE_KERBEROS5=yes Judging by the amount of work going into the krb5 stuff, I was wondering if this warning was valid or just something that didn't get pulled out. -gordon On Mon, 5 Mar 2001, Jacques A. Vidrine wrote: Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing support in FreeBSD for large file sizes?
On Mon, 5 Mar 2001, Matthew Jacob wrote: Very annoying. And Maxtor also missed that Networker is available for FreeBSD as well. And Veritas NetBackup BusinesServer/DataCenter. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
Gordon Tetlow [EMAIL PROTECTED] writes: BTW, is this still valid? From /etc/defaults/make.conf: # Kerberos 5 # If you want KerberosIV (KTH Heimdal), define this: # ** WARNING ** # ** WARNING ** This is very experimental at this stage. If you # ** WARNING ** need stable Kerberos5, rather use the port(s). # ** WARNING ** # #MAKE_KERBEROS5=yes I don't think so. It's the same version that the port currently, even thought the port builds more programs. I've nuked the warning. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Heimdal and pam_kerberos5 (was Re: cvs commit: src/kerberos5/usr.bin [...])
On Mon, Mar 05, 2001 at 03:20:18PM +0100, Assar Westerlund wrote:
"Jacques A. Vidrine" [EMAIL PROTECTED] writes:
Will we always have this dichotomy between kblah/k5blah utilities? It is
fairly annoying. Anecdotally, there don't seem to be many new Kerberos
IV installations, Kerberos V's utilities can get/list/trash version 4
5 tickets.
Yes. My current plan of things to happen (in -current and after 4.3)
is to ditch the v4 programs basically and install the v5 ones under
the canonical names (with v4-compatibility if compiled in). And to
always build and install the krb5 programs/libraries, but ifdef'ing
the support in other programs. How does that sounds?
That's what I wanted to hear :-)
By the way. In my faithlessness, I did not expect that 0.3e would be
MFC'd in time for 4.3. I'm pleasantly surprised. However, I would be
sorry that 4.3 shipped without a pam_kerberos5. I am preparing to
leave on holiday, and will not be able to make it happen myself. In
the hopes that someone else can pick up the pieces, I am attaching a
shar that I threw together today. I'm pretty sure that I don't have
the dependencies right, but I can't play with a build world at the
moment.
This contains a pam_kerberos5 module derived from fcusack's (as found
in ports/security/pam_krb5). Unfortunately, it does not appear that
fcusack is maintaining this. I've been maintaining it on an
unofficial basis, initially fixing several bugs and getting it to
build with Heimdal, and then integrating fixes from the Kerberos
mailings lists. In fact, some Linux distributions now apparently use
this `version' from ports/security/pam_krb5.
In short, I think it is appropriate to add it to the source tree so
that it will be maintained. The license is dual BSD/GPL. If this
misses 4.3 it is not the end of the world, but it would be nice. I've
been using the port with consoles, sshd, and xdm (actually wdm) for
four months or so.
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
# This file contains patches and a shar archive. I expect it to
# be invoked as follows:
#
# % (cd /usr/src /bin/sh ${HOME}/pam_kerberos5.shar)
#
echo p - share/mk/bsd.libnames.mk
(sed 's/^X//' |/usr/bin/patch -Ns) 'END-of-share/mk/bsd.libnames.mk'
X--- share/mk/bsd.libnames.mk.orig Sun Mar 4 10:16:23 2001
X+++ share/mk/bsd.libnames.mk Mon Mar 5 11:37:33 2001
X@@ -10,6 +10,7 @@
X LIBKZTAIL?= ${DESTDIR}${LIBDIR}/kztail.o
X
X LIBALIAS?=${DESTDIR}${LIBDIR}/libalias.a
X+LIBASN1?= ${DESTDIR}${LIBDIR}/libasn1.a # XXX in secure dist, not base
X LIBATM?= ${DESTDIR}${LIBDIR}/libatm.a
X LIBC?=${DESTDIR}${LIBDIR}/libc.a
X LIBC_PIC= ${DESTDIR}${LIBDIR}/libc_pic.a
X@@ -35,12 +36,14 @@
X LIBGCC_PIC?= ${DESTDIR}${LIBDIR}/libgcc_pic.a
X LIBGMP?= ${DESTDIR}${LIBDIR}/libgmp.a
X LIBGNUREGEX?= ${DESTDIR}${LIBDIR}/libgnuregex.a
X+LIBGSSAPI?= ${DESTDIR}${LIBDIR}/libgssapi.a # XXX in secure dist, not base
X LIBHISTORY?= ${DESTDIR}${LIBDIR}/libhistory.a
X LIBIPSEC?=${DESTDIR}${LIBDIR}/libipsec.a
X LIBIPX?= ${DESTDIR}${LIBDIR}/libipx.a
X LIBISC?= ${DESTDIR}${LIBDIR}/libisc.a
X LIBKDB?= ${DESTDIR}${LIBDIR}/libkdb.a# XXX in secure dist, not base
X LIBKRB?= ${DESTDIR}${LIBDIR}/libkrb.a# XXX in secure dist, not base
X+LIBKRB5?= ${DESTDIR}${LIBDIR}/libkrb5.a # XXX in secure dist, not base
X LIBKEYCAP?= ${DESTDIR}${LIBDIR}/libkeycap.a
X LIBKVM?= ${DESTDIR}${LIBDIR}/libkvm.a
X LIBL?=${DESTDIR}${LIBDIR}/libl.a
X@@ -76,6 +79,7 @@
X LIBRADIUS?= ${DESTDIR}${LIBDIR}/libradius.a
X LIBREADLINE?= ${DESTDIR}${LIBDIR}/libreadline.a
X LIBRESOLV?= ${DESTDIR}${LIBDIR}/libresolv.a # XXX doesn't exist
X+LIBROKEN?=${DESTDIR}${LIBDIR}/libroken.a # XXX in secure dist, not base
X LIBRPCSVC?= ${DESTDIR}${LIBDIR}/librpcsvc.a
X LIBSCRYPT?= "don't use LIBSCRYPT, use LIBCRYPT"
X LIBDESCRYPT?= "don't use LIBDESCRYPT, use LIBCRYPT"
END-of-share/mk/bsd.libnames.mk
echo p - lib/libpam/modules/Makefile
(sed 's/^X//' |/usr/bin/patch -Ns) 'END-of-lib/libpam/modules/Makefile'
X--- lib/libpam/modules/Makefile.orig Sun Mar 4 10:37:31 2001
X+++ lib/libpam/modules/MakefileMon Mar 5 12:01:39 2001
X@@ -29,7 +29,7 @@
X .if defined(MAKE_KERBEROS4) !defined(NOCRYPT) !defined(NO_OPENSSL)
X SUBDIR+= pam_kerberosIV
X .endif
X-.if defined(MAKE_KERBEROS5__) !defined(NOCRYPT) !defined(NO_OPENSSL)
X+.if defined(MAKE_KERBEROS5) !defined(NOCRYPT) !defined(NO_OPENSSL)
X SUBDIR+= pam_kerberos5
X .endif
X SUBDIR+= pam_opie
END-of-lib/libpam/modules/Makefile
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# lib/libpam/modules/pam_kerberos5
# lib/libpam/modules/pam_kerberos5/Makefile
#
Re: Machines are getting too damn fast
:On Mon, 5 Mar 2001, E.B. Dreger wrote: : :I've got a ServerWorks III HE-SL system with 512MB of two-way :interleaved PC133 SDRAM and dual PIII-800's. Is that close enough? ::-) : :Here is my "memory bandwidth test", much much simpler and less :scientific than Matt's: : :dd if=/dev/zero of=/dev/null bs=10m count=1000 :1000+0 records in :1000+0 records out :1048576 bytes transferred in 23.716504 secs (442129245 bytes/sec) : :I just did a recent 4.2-STABLE 'make -j 4 buildworld' on that system :in just over 34 minutes. Here's the time output: :1980.707u 768.223s 34:20.89 133.3% 1297+1456k 39517+6202io 1661pf+0w That is quite impressive for SDRAM, though I'm not exactly sure what's being measured due to the way /dev/zero and /dev/null operate. On my system the above dd test returns around 883MB/sec so I would guess that it is only doing a read-swipe on the memory. (sony 1.3G / RIMM) apollo:/home/dillon dd if=/dev/zero of=/dev/null bs=10m count=1000 1000+0 records in 1000+0 records out 1048576 bytes transferred in 11.867550 secs (883565697 bytes/sec) On the DELL 2400 I get: 1048576000 bytes transferred in 2.737955 secs (382977810 bytes/sec) The only thing I don't like about this baby is the IBM IDE hard drive's write performance. I only get 10-12 MBytes/sec. Read performance is incredible, though... I get 37MB/sec dd'ing from /dev/ad0s1a to /dev/null. ad0: 58644MB IBM-DTLA-307060 [119150/16/63] at ata0-master UDMA100 -Matt : If one _truly_ needs the bandwidth of Rambus (which, IIRC, is : higher real-world latency than SDRAM), then how about having the : bus bandwidth to back it up? : :The higher real-world latency of RDRAM over SDRAM is what makes the :benefits of its higher bandwidth so questionable. PC2100 DDR-SDRAM -- :which has higher latencies than regular SDRAM but still lower than :RDRAM -- should have it beat soundly, though we'll have to wait for :some systems that are actually designed to take advantage of it to say :for sure. :-) : : :-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
systat -vmstat or iostat IO help
I would like to get a more accurate picture of each. example: webserverabit of a high load..1 ide drive..memory ok [root@lotho dphoenix]# uptime 2:25PM up 2 days, 21:10, 1 user, load averages: 6.94, 8.23, 9.34 [root@lotho dphoenix]# systat -iostat /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 ad0 MB/s tps|XXX acd0 MB/s tps| fd0 MB/s tps| md0 MB/s tps| systat -vmstat Disks ad0 acd0 fd0 md0 89 ofodintrn KB/t 4.35 0.00 0.00 0.00 85 %slo-z61952 buf tps 13 0 0 0 104 tfree42 dirtybuf MB/s 0.05 0.00 0.00 0.00 36095 desiredvnodes % busy 100 0 0 0 58692 numvnodes 43991 freevnodes well vmstat showing 100% busy and iostat showing 10% busy.. IO an issue here or not? -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED]| | make installworld| | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
On Mon, 5 Mar 2001, Matt Dillon wrote: :On Mon, 5 Mar 2001, E.B. Dreger wrote: : :I've got a ServerWorks III HE-SL system with 512MB of two-way :interleaved PC133 SDRAM and dual PIII-800's. Is that close enough? ::-) : :Here is my "memory bandwidth test", much much simpler and less :scientific than Matt's: : :dd if=/dev/zero of=/dev/null bs=10m count=1000 :1000+0 records in :1000+0 records out :1048576 bytes transferred in 23.716504 secs (442129245 bytes/sec) : :I just did a recent 4.2-STABLE 'make -j 4 buildworld' on that system :in just over 34 minutes. Here's the time output: :1980.707u 768.223s 34:20.89 133.3% 1297+1456k 39517+6202io 1661pf+0w That is quite impressive for SDRAM, though I'm not exactly sure what's being measured due to the way /dev/zero and /dev/null operate. On my system the above dd test returns around 883MB/sec so I would guess that it is only doing a read-swipe on the memory. I figured if /dev/null and /dev/zero had relatively little memory impact, which I figure is the case, it would matter more how dd does its blocking. If you reduce the blocksize to something that will fit in your L2 caches, you'll see a very significant increase in throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its overclocked) here on my desk with 256KB L2 cache: dd if=/dev/zero of=/dev/null bs=10m count=200 200+0 records in 200+0 records out 2097152000 bytes transferred in 10.032157 secs (209042982 bytes/sec) dd if=/dev/zero of=/dev/null bs=512k count=4000 4000+0 records in 4000+0 records out 2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec) dd if=/dev/zero of=/dev/null bs=128k count=16000 16000+0 records in 16000+0 records out 2097152000 bytes transferred in 1.204001 secs (1741819224 bytes/sec) Now THAT is a significant difference. :-) (sony 1.3G / RIMM) apollo:/home/dillon dd if=/dev/zero of=/dev/null bs=10m count=1000 1000+0 records in 1000+0 records out 1048576 bytes transferred in 11.867550 secs (883565697 bytes/sec) Very impressive. Looks about right given the theoretical maximum bandwidth of your memory system. From what I've been gathering, that dd-test shows roughly 1/4 of the total theoretical memory bandwidth (two reads and two writes happening?), minus any chipset deficiencies when it comes to memory transfers. For example, this PIII-850 on a BX board is actually an overclocked 700MHz 100MHz FSB PIII. So, it is using a 116MHz FSB and the SDRAM is running at that speed as well. The theoretical maximum bandwidth of this should be 8(bytes-per-clock)*116(MHz)=928MB/sec. I'm seeing about 210MB/sec on the dd-test, so thats pretty close to 1/4. In your case, you are using PC800 RDRAM on a Pentium-4 system on an i850 board, which IIRC uses a dual-channel RDRAM setup, theoretically doubling the bandwidth that you could get with only one channel. Since you're using dual RDRAM channels of PC800 RDRAM, that would be 4(bytes-per-clock)*800(MHz)=3200MB/sec. Again, the dd-test is pretty close to 1/4 the total theoretical bandwidth (actually a little over), since you achieved about 883MB/sec. In an HE-SL system I have here, it uses dual-interleaved PC133 SDRAM. That would be 16(bytes-per-clock)*133(MHz)=2128MB/sec. The dd-test is a little off the mark of 1/4 the theoretical maximum bandwidth at 442MB/sec, but this thing is the only system I've seen the dd-test on so far that hasn't used an Intel chipset. The Intel chipsets have shown in other benchmarks to be more efficient than anybody else's chipsets (VIA, AMD, RCC, etc) at doing the memory thing, so that makes sense. I think I'm on to something here with this 'cheap' dd-test. :-) A PC2100 DDR-SDRAM system will have a theoretical bandwidth of 2100MB/sec (duh), so a dd-test should come out to around 525MB/sec. I'm guessing it will actually be a bit less since the AMD and especially VIA chipsets aren't going to be anywhere near as efficient as the Intels have been. I'm guessing 95% efficiency for the AMD, so about 500MB/sec from the dd-test. 85% efficient for the VIA, so around 450MB/sec. Anyone care to test that on one or both of the new AMD-chipset and VIA-chipset DDR systems and see how close it comes? :-) The only thing I don't like about this baby is the IBM IDE hard drive's write performance. I only get 10-12 MBytes/sec. Read performance is incredible, though... I get 37MB/sec dd'ing from /dev/ad0s1a to /dev/null. ad0: 58644MB IBM-DTLA-307060 [119150/16/63] at ata0-master UDMA100 That is a 75GXP series, which is supposed to be one of the fastest, if not the fastest, IDE drive on the market right now. Hmm. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe
Fix for scrambled top display on SMP [PR 22270]
It's just three lines of code. :) I have SMP machines here that have some pretty absurdly long usernames thanks to some NIS accounts (20+ chars). Unfortunately the namelength truncation code in /usr/bin/top currently doesn't take into account the 'C' (last CPU) field that SMP machines have. This patch makes long names just a little shorter so that the display doesn't wrap weirdly on a 80 column display. http://www.freebsd.org/cgi/query-pr.cgi?pr=22270 PR's been stale for a bit so I thought I'd draw some attention. wink Thanks for reading. -- Andy Carrel - [EMAIL PROTECTED] - +1 (206) 357-4607 Internet Sys. Eng. - Enterprise Infrastructure Security - InfoSpace To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
fixing flex definitions?
The flex scanner template has this in it: #ifndef YY_ALWAYS_INTERACTIVE #ifndef YY_NEVER_INTERACTIVE extern int isatty YY_PROTO(( int )); #endif #endif Which seems to be the wrong thing to do. Would this be an ok fix? I'm worried about the YY_PROTO() messing things up anyone know what the point of doing it this way is? Index: flex.skl === RCS file: /home/ncvs/src/usr.bin/lex/flex.skl,v retrieving revision 1.4 diff -u -u -r1.4 flex.skl --- flex.skl1999/10/27 07:56:44 1.4 +++ flex.skl2001/03/05 22:49:01 @@ -1180,7 +1180,8 @@ %- #ifndef YY_ALWAYS_INTERACTIVE #ifndef YY_NEVER_INTERACTIVE -extern int isatty YY_PROTO(( int )); +/* for isatty() */ +#include unistd.h #endif #endif -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: fixing flex definitions?
On 05-Mar-01 Alfred Perlstein wrote: The flex scanner template has this in it: #ifndef YY_ALWAYS_INTERACTIVE #ifndef YY_NEVER_INTERACTIVE extern int isatty YY_PROTO(( int )); #endif #endif Which seems to be the wrong thing to do. Would this be an ok fix? I'm worried about the YY_PROTO() messing things up anyone know what the point of doing it this way is? I'm guessing YY_PROTO is like __P() so it can be "compilable with a KR Old Testament compiler." -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fixing flex definitions?
On Mon, Mar 05, 2001 at 02:55:22PM -0800, John Baldwin wrote: I'm guessing YY_PROTO is like __P() so it can be "compilable with a KR Old Testament compiler." Yes. And in this case, the output of lex *must* be portable to KR. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Strange, possibly network-related, crashes
I'm having some problems with a 4.2-Release NAT box. If I leave it up and connected to the outside world for a couple of days, it starts crashing with a page not found type of error (I'm sorry I don't have the full text of the error - it finishes crashing and reboots before I can read the error from the screen). It will continue to come up, then crash, repeatedly, until I turn it off or disconnect it from the outside world. This has happened twice since I set the box up, and it takes two to three days for the fun to begin. I had 4.0 installed on the same machine, and I never had any problems with it: it would stay up for months at a time, with little intervention on my part. The problems started when I made the following changes to the machine: 1. I upgraded the OS to 4.2 2. I installed an 802.11 PCI card The machine is currently configured with two intel FE network cards (using the fxp device), and a Cisco AiroNet 340 802.11 card (using the an device). If someone has any idea as to what this might be, that would be cool if you could tell me. However, I don't expect that kind of luck. I'm interested in information on how to get the kernel to drop to the debugger when it wrecks like that, so I can fix the problem myself, or write a more useful query to this list. -- Gary Jackson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fixing flex definitions?
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes : Would this be an ok fix? I'm worried about the YY_PROTO() messing things up anyone know what the point of doing it this way is? Compatability with pre-ANSI 'C' compilers, just like __P from /usr/include/sys/cdefs.h. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
:throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its :overclocked) here on my desk with 256KB L2 cache: : :dd if=/dev/zero of=/dev/null bs=512k count=4000 :4000+0 records in :4000+0 records out :2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec) : :dd if=/dev/zero of=/dev/null bs=128k count=16000 :16000+0 records in :16000+0 records out :2097152000 bytes transferred in 1.204001 secs (1741819224 bytes/sec) : :Now THAT is a significant difference. :-) Interesting. I get very different results with the 1.3 GHz P4. The best I seem to get is 1.4 GBytes/sec. I'm not sure what the L2 cache is on the box, but it's definitely a consumer model. dd if=/dev/zero of=/dev/null bs=512k count=4000 2097152000 bytes transferred in 2.363903 secs (887156520 bytes/sec) dd if=/dev/zero of=/dev/null bs=128k count=16000 2097152000 bytes transferred in 1.471046 secs (1425619621 bytes/sec) If I use lower block sizes the syscall overhead blows up the performance (it gets lower rather then higher). So I figure I don't have as much L2 as on your system. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
:IIRC, Intel is using a very different caching method on the P4 from
:what we are used to on just about every other x86 processor we've
:seen. Well, I can't remember if the data cache has changed much, but
:the instruction cache has. I doubt the difference in instruction
:cache behaviour would make a difference here though. Hmm.
:
:I wonder if it makes any difference that I'm using -march=pentium
:-mcpu=pentium for my CFLAGS? Actually, the kernel I tested on might
:even be using -march/-mcpu=pentiumpro, since I only recently changed
:it to =pentium to allow me to do buildworlds for another Pentium-class
:machine. I did wonder the same thing a while back and did the same
:test with and without the optimizations, and with pentiumpro opts the
:big block size transfer rate went _down_ a little bit, which was odd.
:I didn't compare with L2-cache-friendly blocks, though.
:
:-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
I modified my original C program again, this time to simply read
the data from memory given a block size in kilobytes as an argument.
I had to throw in a little __asm to do it right, but here are my results.
It shows about 3.2 GBytes/sec from the L2 (well, insofar as my
3-instruction loop goes), and about 1.4 GBytes/sec from main memory.
NOTE: cc x.c -O2 -o x
./x 4
3124.96 MBytes/sec (read)
./x 8
3242.45 MBytes/sec (read)
./x 16
3060.93 MBytes/sec (read)
./x 32
3359.97 MBytes/sec (read)
./x 64
3362.06 MBytes/sec (read)
./x 128
3365.53 MBytes/sec (read)
./x 240
3307.86 MBytes/sec (read)
./x 256
3232.33 MBytes/sec (read)
./x 512
1396.45 MBytes/sec (read)
./x 1024
1397.90 MBytes/sec (read)
In contrast I get 1052.50 MBytes/sec on the Dell 2400 from the L2,
and 444 MBytes/sec from main memory.
-Matt
/*
* NOTE: cc x.c -O2 -o x
*/
#include sys/types.h
#include sys/time.h
#include stdio.h
#include stdlib.h
#include stdarg.h
#include unistd.h
int deltausecs(struct timeval *tv1, struct timeval *tv2);
int
main(int ac, char **av)
{
int i;
int bytes;
double dtime;
struct timeval tv1;
struct timeval tv2;
char *buf;
if (ac == 1) {
fprintf(stderr, "%s numKB\n", av[0]);
exit(1);
}
bytes = strtol(av[1], NULL, 0) * 1024;
if (bytes 4 * 1024 || bytes 256 * 1024 * 1024) {
fprintf(stderr, "Oh please. Try a reasonable value\n");
exit(1);
}
buf = malloc(bytes);
if (buf == NULL) {
perror("malloc");
exit(1);
}
bzero(buf, bytes);
gettimeofday(tv1, NULL);
for (i = 0; i 10; i += bytes) {
register int j;
for (j = bytes - 4; j = 0; j -= 4)
__asm __volatile("movl (%0,%1),%%eax" :
"=r" (buf), "=r" (j) :
"0" (buf), "1" (j) : "ax" );
}
gettimeofday(tv2, NULL);
dtime = (double)deltausecs(tv1, tv2);
printf("%6.2f MBytes/sec (read)\n", (double)10 / dtime);
return(0);
}
int
deltausecs(struct timeval *tv1, struct timeval *tv2)
{
int usec;
usec = (tv2-tv_usec + 100 - tv1-tv_usec);
usec += (tv2-tv_sec - tv1-tv_sec - 1) * 100;
return(usec);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing support in FreeBSD for large file sizes?
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : What I can't understand is the reference to missing support for large : file sizes - as far as I know, that's one of FreeBSD's strengths! Anybody : care to guess what they mean here? It is crap. FreeBSD's API supports up to 2^63 byte files, but the kernel internal structures limit this to 2^41, or 2TB. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
:systat -vmstat : :Disks ad0 acd0 fd0 md0 89 ofodintrn :KB/t 4.35 0.00 0.00 0.00 85 %slo-z61952 buf :tps 13 0 0 0 104 tfree42 dirtybuf :MB/s 0.05 0.00 0.00 0.00 36095 desiredvnodes :% busy 100 0 0 0 58692 numvnodes : :well vmstat showing 100% busy and iostat showing 10% busy.. :IO an issue here or not? :... :Dan systat -vmstat is correct. I usually use 'systat -vm 1'. If you see 100% busy for more then a few seconds then the disk is saturated (almost certainly seek-limited). Solutions depend on what the system is doing. Mail systems are the least scaleable, requiring you to add additional disks for spools or a stripe, or additional machines and use an MX round robin. Most other services can be scaled well simply by adding memory or cpu. SCSI disks usually do better then IDE in seek-limited situations. Higher-RPM disks can make a big difference too. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing support in FreeBSD for large file sizes?
On Monday, 5 March 2001 at 17:23:53 -0700, Warner Losh wrote: In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: What I can't understand is the reference to missing support for large file sizes - as far as I know, that's one of FreeBSD's strengths! Anybody care to guess what they mean here? It is crap. FreeBSD's API supports up to 2^63 byte files, but the kernel internal structures limit this to 2^41, or 2TB. In fact, at the moment we don't seem to be able to build file systems of more than 1 TB. This may be a bug. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
: : : :this is a webserver ..i am trying to figure out if cpu increase or :scsi drives is better in this situation. Right now...that is a big :decision because there are approx 30 fbsd webservers not all showing :high IO from vmstat...just the ones with the highest uptime. :... Check the memory load with 'systat -vm 1'... if you are swapping a lot simply adding more memory may solve the problem. Generally speaking, adding more memory to a web server helps a lot even if you aren't swapping because web servers tend to be heavy on reading files. Today's machines are powerful enough that you can serve thousands of users off a single host, but drive technology isn't powerful enough to serve large datasets off a single drive so you need a lot of ram for cache. For example, a 20G hard drive may be able to store 20G worth of files, but it sure won't be able to keep up with a heavily loaded webserver unless you have a lot of ram for caching. Drive seek times tend to top out at 6ms, or 166 seeks per second, and without sufficient memory to cache the web pages this will result in severe limitations to the number of hits/sec the webserver can handle. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing support in FreeBSD for large file sizes?
Hello sthaug, Tuesday, March 06, 2001, 1:24:24 AM, you wrote: snn According to the "Maxtor picks Windows, dumps open source" article at snn http://news.cnet.com/news/0-1003-200-5009496.html?tag=lh snn FreeBSD "did not support large file sizes, Macintosh and newer Novell snn file systems, or backup and management software from companies such as snn OpenView, Tivoli and Microsoft". snn Now I can understand what they say about missing Tivoli support - we're snn using Tivoli backup here ourselves, and the SCO ADSM/TSM client that we snn currently use to backup FreeBSD is passable, but nothing more. A native snn FreeBSD client would be much preferable. snn What I can't understand is the reference to missing support for large snn file sizes - as far as I know, that's one of FreeBSD's strengths! Anybody snn care to guess what they mean here? snn Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] snn To Unsubscribe: send mail to [EMAIL PROTECTED] snn with "unsubscribe freebsd-hackers" in the body of the message this is a stupid decision, let they go. AFAIK, Windows 2000 does not support dump file system to tape or other medias. I was a Windows NT system manager, I know I don't believe all backup softwares for Windows NT, simply because Windows NT system can not be fully backuped. FreeBSD can do, it's strength of Unix File System. -- Best regards, David Xu mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
Well we use php mostly. I noticed from moving from php3 to php4 memory consumption on webservers was just incredible and had to increase ram from 256 megs to 500megs on each of webservers. Memory is fine now. [root@lotho dphoenix]# ps aux|grep httpd|wc -l 65 [root@lotho dphoenix]# top |grep -i mem Mem: 193M Active, 138M Inact, 89M Wired, 33M Cache, 61M Buf, 46M Free [root@lotho dphoenix]# uptime 5:06PM up 2 days, 23:51, 1 user, load averages: 3.29, 1.94, 1.70 [root@lotho dphoenix]# load is down now cause peak is off but systat -vm 1 showed about 3-4 seconds of 100% then 1 sec of 0 then 3-4 sec of 100% again...etc. Another factor is mysql with persistant database connections. Waiting on a request back from the mysql server could cause some IO as well i could imagine...another factor. Only thing I have never been able to figure out is how to kill persistant connections when a mysql server goes down. Let's say i drop a mysql serverall the webservers will use up all ram and swap till machine just drops using up all it's resources.effect on freebsd is unable to free vm free_pages and machine pretty much crashes and requires a hard reboot. There is no fix for thiswe have solved some of this bye setting semaphores on site to tell webservers that mysql server is down...then restart apache on those webservers to kill persistant connections to db's. But I am going offtopicmemory is not an issue. So real question is how to calculate then if the drive is doing more than say 166 seeks on disk per sec. Any great tool out there :) On Mon, 5 Mar 2001, Matt Dillon wrote: Date: Mon, 5 Mar 2001 17:02:15 -0800 (PST) From: Matt Dillon [EMAIL PROTECTED] To: Dan Phoenix [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: systat -vmstat or iostat IO help : : : :this is a webserver ..i am trying to figure out if cpu increase or :scsi drives is better in this situation. Right now...that is a big :decision because there are approx 30 fbsd webservers not all showing :high IO from vmstat...just the ones with the highest uptime. :... Check the memory load with 'systat -vm 1'... if you are swapping a lot simply adding more memory may solve the problem. Generally speaking, adding more memory to a web server helps a lot even if you aren't swapping because web servers tend to be heavy on reading files. Today's machines are powerful enough that you can serve thousands of users off a single host, but drive technology isn't powerful enough to serve large datasets off a single drive so you need a lot of ram for cache. For example, a 20G hard drive may be able to store 20G worth of files, but it sure won't be able to keep up with a heavily loaded webserver unless you have a lot of ram for caching. Drive seek times tend to top out at 6ms, or 166 seeks per second, and without sufficient memory to cache the web pages this will result in severe limitations to the number of hits/sec the webserver can handle. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
:Well we use php mostly. I noticed from moving from php3 to php4 :memory consumption on webservers was just incredible and had to :increase ram from 256 megs to 500megs on each of webservers. :Memory is fine now. : :[root@lotho dphoenix]# ps aux|grep httpd|wc -l : 65 :[root@lotho dphoenix]# top |grep -i mem :Mem: 193M Active, 138M Inact, 89M Wired, 33M Cache, 61M Buf, 46M Free :[root@lotho dphoenix]# uptime : 5:06PM up 2 days, 23:51, 1 user, load averages: 3.29, 1.94, 1.70 :[root@lotho dphoenix]# : :load is down now cause peak is off but systat -vm 1 showed about 3-4 :seconds of 100% then 1 sec of 0 then 3-4 sec of 100% again...etc. :Another factor is mysql with persistant database connections. :Waiting on a request back from the mysql server could cause some IO You shouldn't have 46MB free. You should have maybe 10MB free. 46MB free would seem to indicate that some progrma is eating a large chunk of memory and then exiting, blowing a big piece of the disk cache away in the process. I would monitor the machine's memory and disk I/O closely to try to figure out which process or processes are responsible. :as well i could imagine...another factor. Only thing I have never been :able to figure out is how to kill persistant connections when a mysql :server goes down. Let's say i drop a mysql serverall the webservers :will use up all ram and swap till machine just drops using up all it's :resources.effect on freebsd is unable to free vm free_pages and Dunno, but it sounds like a problem you need solve. At the very least set Apache's connection limit so Apache stops working before the machine would otherwise die. :But I am going offtopicmemory is not an issue. So real question :is how to calculate then if the drive is doing more than say 166 seeks on :disk per sec. Any great tool out there :) Memory is always an issue when you have a saturated drive unless the saturation is being caused by a lots of write I/O. For a script, probably the easiest thing to do is to pipe (the continuous) 'iostat ad0 10' output to a script and have the script pull out the tps field and do something with it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
[Mon Mar 5 11:04:01 2001] [error] (54)Connection reset by peer: getsockname [Mon Mar 5 11:04:01 2001] [error] (54)Connection reset by peer: getsockname i see that from apache error log i have seen that is past from a)either maxclients being set to low or b) freebsd maxusers set to low neither is the case on this machine. from /var/log/messages i see Mar 4 23:00:47 drago postfix/flush[73473]: fatal: accept connection: Software caused connection abort Mar 4 23:17:27 drago postfix/flush[74329]: fatal: accept connection: Software caused connection abort Mar 4 23:34:07 drago postfix/flush[75360]: fatal: accept connection: Software caused connection abort Mar 4 23:34:48 drago /kernel: pid 65438 (httpd), uid 506: exited on signal 10 ok httpd exiting of signal 10.that is a bad one. only 2 things really running on webservers are apache and postfix. all postfix does on webservers is just dish mail off to mail servers, so apache is my concern. Max clients is not set to low. [root@drago dphoenix]# top |grep -i mem Mem: 128M Active, 169M Inact, 77M Wired, 22M Cache, 61M Buf, 106M Free Active: number of pages active Inact: number of pages inactive Wired: number of pages wired down, including cached file data pages Cache: number of pages used for VM-level disk caching Buf: number of pages used for BIO-level disk caching Free: number of pages free Total: total available swap usage I am trying to figure out corelation between Inactive and Free then. Inact would be unused ram right? Free would be what how much of Active is being used? So what you are saying is if there is to much free then alot of active pages are being killed for some reason...as seen in error logs etc? just trying to get a quick overview of what a good accessment that was...never thought of that. On Mon, 5 Mar 2001, Matt Dillon wrote: Date: Mon, 5 Mar 2001 17:24:58 -0800 (PST) From: Matt Dillon [EMAIL PROTECTED] To: Dan Phoenix [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: systat -vmstat or iostat IO help :Well we use php mostly. I noticed from moving from php3 to php4 :memory consumption on webservers was just incredible and had to :increase ram from 256 megs to 500megs on each of webservers. :Memory is fine now. : :[root@lotho dphoenix]# ps aux|grep httpd|wc -l : 65 :[root@lotho dphoenix]# top |grep -i mem :Mem: 193M Active, 138M Inact, 89M Wired, 33M Cache, 61M Buf, 46M Free :[root@lotho dphoenix]# uptime : 5:06PM up 2 days, 23:51, 1 user, load averages: 3.29, 1.94, 1.70 :[root@lotho dphoenix]# : :load is down now cause peak is off but systat -vm 1 showed about 3-4 :seconds of 100% then 1 sec of 0 then 3-4 sec of 100% again...etc. :Another factor is mysql with persistant database connections. :Waiting on a request back from the mysql server could cause some IO You shouldn't have 46MB free. You should have maybe 10MB free. 46MB free would seem to indicate that some progrma is eating a large chunk of memory and then exiting, blowing a big piece of the disk cache away in the process. I would monitor the machine's memory and disk I/O closely to try to figure out which process or processes are responsible. :as well i could imagine...another factor. Only thing I have never been :able to figure out is how to kill persistant connections when a mysql :server goes down. Let's say i drop a mysql serverall the webservers :will use up all ram and swap till machine just drops using up all it's :resources.effect on freebsd is unable to free vm free_pages and Dunno, but it sounds like a problem you need solve. At the very least set Apache's connection limit so Apache stops working before the machine would otherwise die. :But I am going offtopicmemory is not an issue. So real question :is how to calculate then if the drive is doing more than say 166 seeks on :disk per sec. Any great tool out there :) Memory is always an issue when you have a saturated drive unless the saturation is being caused by a lots of write I/O. For a script, probably the easiest thing to do is to pipe (the continuous) 'iostat ad0 10' output to a script and have the script pull out the tps field and do something with it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
I guess that machien was a bad example as it is doing well right now. I will have to wait till peak time again to monitor it. On Mon, 5 Mar 2001, Dan Phoenix wrote: Date: Mon, 5 Mar 2001 17:51:22 -0800 (PST) From: Dan Phoenix [EMAIL PROTECTED] To: Matt Dillon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: systat -vmstat or iostat IO help [Mon Mar 5 11:04:01 2001] [error] (54)Connection reset by peer: getsockname [Mon Mar 5 11:04:01 2001] [error] (54)Connection reset by peer: getsockname i see that from apache error log i have seen that is past from a)either maxclients being set to low or b) freebsd maxusers set to low neither is the case on this machine. from /var/log/messages i see Mar 4 23:00:47 drago postfix/flush[73473]: fatal: accept connection: Software caused connection abort Mar 4 23:17:27 drago postfix/flush[74329]: fatal: accept connection: Software caused connection abort Mar 4 23:34:07 drago postfix/flush[75360]: fatal: accept connection: Software caused connection abort Mar 4 23:34:48 drago /kernel: pid 65438 (httpd), uid 506: exited on signal 10 ok httpd exiting of signal 10.that is a bad one. only 2 things really running on webservers are apache and postfix. all postfix does on webservers is just dish mail off to mail servers, so apache is my concern. Max clients is not set to low. [root@drago dphoenix]# top |grep -i mem Mem: 128M Active, 169M Inact, 77M Wired, 22M Cache, 61M Buf, 106M Free Active: number of pages active Inact: number of pages inactive Wired: number of pages wired down, including cached file data pages Cache: number of pages used for VM-level disk caching Buf: number of pages used for BIO-level disk caching Free: number of pages free Total: total available swap usage I am trying to figure out corelation between Inactive and Free then. Inact would be unused ram right? Free would be what how much of Active is being used? So what you are saying is if there is to much free then alot of active pages are being killed for some reason...as seen in error logs etc? just trying to get a quick overview of what a good accessment that was...never thought of that. On Mon, 5 Mar 2001, Matt Dillon wrote: Date: Mon, 5 Mar 2001 17:24:58 -0800 (PST) From: Matt Dillon [EMAIL PROTECTED] To: Dan Phoenix [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: systat -vmstat or iostat IO help :Well we use php mostly. I noticed from moving from php3 to php4 :memory consumption on webservers was just incredible and had to :increase ram from 256 megs to 500megs on each of webservers. :Memory is fine now. : :[root@lotho dphoenix]# ps aux|grep httpd|wc -l : 65 :[root@lotho dphoenix]# top |grep -i mem :Mem: 193M Active, 138M Inact, 89M Wired, 33M Cache, 61M Buf, 46M Free :[root@lotho dphoenix]# uptime : 5:06PM up 2 days, 23:51, 1 user, load averages: 3.29, 1.94, 1.70 :[root@lotho dphoenix]# : :load is down now cause peak is off but systat -vm 1 showed about 3-4 :seconds of 100% then 1 sec of 0 then 3-4 sec of 100% again...etc. :Another factor is mysql with persistant database connections. :Waiting on a request back from the mysql server could cause some IO You shouldn't have 46MB free. You should have maybe 10MB free. 46MB free would seem to indicate that some progrma is eating a large chunk of memory and then exiting, blowing a big piece of the disk cache away in the process. I would monitor the machine's memory and disk I/O closely to try to figure out which process or processes are responsible. :as well i could imagine...another factor. Only thing I have never been :able to figure out is how to kill persistant connections when a mysql :server goes down. Let's say i drop a mysql serverall the webservers :will use up all ram and swap till machine just drops using up all it's :resources.effect on freebsd is unable to free vm free_pages and Dunno, but it sounds like a problem you need solve. At the very least set Apache's connection limit so Apache stops working before the machine would otherwise die. :But I am going offtopicmemory is not an issue. So real question :is how to calculate then if the drive is doing more than say 166 seeks on :disk per sec. Any great tool out there :) Memory is always an issue when you have a saturated drive unless the saturation is being caused by a lots of write I/O. For a script, probably the easiest thing to do is to pipe (the continuous) 'iostat ad0 10' output to a script and have the script pull out the tps field and do something with it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe
Re: systat -vmstat or iostat IO help
:I am trying to figure out corelation between Inactive and Free then. :Inact would be unused ram right? :Free would be what how much of Active is being used? So what you are :saying is if there is to much free then alot of active pages are being :killed for some reason...as seen in error logs etc? just trying to get :a quick overview of what a good accessment that was...never thought of :that. 'free' (from systat -vm or top) is all that matters in your case. Active/Inactive/Cache are best simply added together. Their individual values will depend heavily on the load on the machine because the VM system doesn't bother to keep things in their proper queues if the memory load is low. Normally when a machine is operating you see the 'free' value drop steadily until it hits vm.v_free_min, which is typically 2-4 MB. The VM system then frees up inactive cache memory up to vm.v_free_target, which is typically around 10MB. Thus the 'free' value will recover to around 10MB, then drop and recover again, add nauseum. Once free memory drops you should never see it get big again unless you run a program which allocates a whole bunch of memory (e.g. 40MB) and then exits. The allocated memory is freed on program exit and may temporarily bump the 'free' value up, but it should steadily drop again and restabilize at 4-10MB or so. Alternatively it is possible that a whole bunch of programs may be started at once and then all exit at around the same time, resulting in the same effect. If you regularly see a large free value (aka 40MB) plus lots of disk activity, something weird may be going on that you need to track down and figure out. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
Dan Phoenix [EMAIL PROTECTED] writes: systat -iostat /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 ad0 MB/s tps|XXX [...] systat -vmstat Disks ad0 acd0 fd0 md0 89 ofodintrn KB/t 4.35 0.00 0.00 0.00 85 %slo-z61952 buf tps 13 0 0 0 104 tfree42 dirtybuf MB/s 0.05 0.00 0.00 0.00 36095 desiredvnodes % busy 100 0 0 0 58692 numvnodes 43991 freevnodes well vmstat showing 100% busy and iostat showing 10% busy.. No, -vmstat and -iostat are showing 13 and 12 tps (transactions per second), respectively. -iostat doesn't show a "busy percentage". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
