Re: FreeBSD and ISCSI, Strange Problem
I'm with a very strange problem in the FreeBSD 7.0R I use the iscsi_initiator to mount two devices of a Dell MD3000i, the file system is UFS. The problem occurs when I make a copy of a great directory for inside of the /data/email directory, passed some minutes of beginning of copy, the SSH connection stops to answer, when trying to open a new connection Password: it isn't requested, in the console, when typing the user root e to press enter, Password: also it isn't requested. The only way to come back is restarting the FreeBSD. When press CTRL+T during the freeze it is shown: # ssh [EMAIL PROTECTED] load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k In another freeze it showed state [ufs] During freeze, send and receive pings work fine, but no service runing work. I already verified for some related LOG, however not see nothing related. hi Daniel, the problem is probably that iscsi is deadlocked, so fetch ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gz cd /usr/src tar xpzf /path-to-tar-file/iscsi-2.1.tar.gz (cd sys/modules/iscsi/initiator; make; make install) (cd sbin/iscontrol;make; make install) probably the safest is now to reboot. Let me know what happens. obrigado (thanks?), danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
bad NFS/UDP performance
Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? thanks, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? 1) Network card driver changes, 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Major SMP problems with lstat/namei
Jeff Wheelhouse [EMAIL PROTECTED] writes: http://software.wheelhouse.org/rptest.tar.bz2 Thanks. I get similar results on head; vfs.lookup_shared actually seems to *reduce* performance by about 10% - 20%. I ran the test on both UFS and ZFS; there is no significant difference. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? 1) Network card driver changes, could be, but at least iperf/tcp is ok - can't get udp numbers, do you know of any tool to measure udp performance? BTW, I also checked on different hardware, and the badness is there. 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html gut feeling is that it's somewhere else: Writing 16 MB file BSCount / 7.0 --/ / 7.1 -/ 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s 64*512512 0.22s 71.45MB/s 0.45s 35.41MB/s 128*512256 0.21s 77.84MB/s 0.51s 31.34MB/s 256*512128 0.19s 82.47MB/s 0.43s 37.22MB/s 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s Average: 75.8633.00 the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in the measurements, but the relation are similar, good on 7.0, bad on 7.1 Cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? 1) Network card driver changes, could be, but at least iperf/tcp is ok - can't get udp numbers, do you know of any tool to measure udp performance? BTW, I also checked on different hardware, and the badness is there. According to INDEX, benchmarks/iperf does UDP bandwidth testing. benchmarks/nttcp should as well. What network card is in use? If Intel, what driver version (should be in dmesg). 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html gut feeling is that it's somewhere else: Writing 16 MB file BSCount / 7.0 --/ / 7.1 -/ 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s 64*512512 0.22s 71.45MB/s 0.45s 35.41MB/s 128*512256 0.21s 77.84MB/s 0.51s 31.34MB/s 256*512128 0.19s 82.47MB/s 0.43s 37.22MB/s 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s Average: 75.8633.00 the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in the measurements, but the relation are similar, good on 7.0, bad on 7.1 Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Rare problems in upgrade process (corrupted FS?)
Hi all, I'm traying to update a FreeBSD server box from 6.3p11 to 7.0 and I've found a rare problems. 1) I do the sync process with csup(1); next I go into /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized kernels) and this file doesn't exists. Mmmm I decide to repeat the process againt other cvsup mirror but I get the same results: GENERIC file isn't there. 2) I go to FreeBSD CVSWeb , locate the GENERIC file under the 7_0 tag, copy and paste. Yes, I know: a very nasty process. The big problem appears when I try to do 'make cleandir' and others. I get the next outputs: # pwd /usr/src # make cleandir make: don't know how to make cleandir. Stop # make buildworld make: don't know how to make buildworld. Stop # ls -l /usr/bin/make -r-xr-xr-x 1 root wheel 351024 Aug 18 13:19 /usr/bin/make # file /usr/bin/make /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for FreeBSD 6.3, statically linked, stripped ¿?¿?¿?¿ * I reboot the machine (because of I suspect a very weird FS problem), boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) found and repair several errors. Epecially, one error claims my attention: SUPERBLOCK. * After the theorical FS reparation I'm again in the point 1. ¿Any clues? -- Thanks, Jordi Espasa Clofent ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rare problems in upgrade process (corrupted FS?)
On Fri, Sep 26, 2008 at 12:22:55PM +0200, Jordi Espasa Clofent wrote: Hi all, I'm traying to update a FreeBSD server box from 6.3p11 to 7.0 and I've found a rare problems. 1) I do the sync process with csup(1); next I go into /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized kernels) and this file doesn't exists. Mmmm I decide to repeat the process againt other cvsup mirror but I get the same results: GENERIC file isn't there. 2) I go to FreeBSD CVSWeb , locate the GENERIC file under the 7_0 tag, copy and paste. Yes, I know: a very nasty process. The big problem appears when I try to do 'make cleandir' and others. I get the next outputs: # pwd /usr/src # make cleandir make: don't know how to make cleandir. Stop # make buildworld make: don't know how to make buildworld. Stop # ls -l /usr/bin/make -r-xr-xr-x 1 root wheel 351024 Aug 18 13:19 /usr/bin/make # file /usr/bin/make /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for FreeBSD 6.3, statically linked, stripped Looks to me like you have no /usr/src/Makefile. * After the theorical FS reparation I'm again in the point 1. None of the information you provided in your above output, however, shows anything about the filesystem (other than /usr/bin/make). But this sounds honestly like some sort of corrupted supdb, or a cvsup mirror that's broken. I would do the following: rm -fr /usr/src/* rm -fr /var/db/sup/src-all csup -h cvsupserver -L 2 -g /usr/share/examples/stable-supfile I can assure you /sys/amd64/conf/GENERIC exists, and is on the cvsup mirrors. * I reboot the machine (because of I suspect a very weird FS problem), boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) found and repair several errors. Epecially, one error claims my attention: SUPERBLOCK. Superblock problems wouldn't explain this; there are hundreds of superblocks available (you wouldn't be able to use your machine if they were all horked). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rare problems in upgrade process (corrupted FS?)
On 2008-Sep-26 12:22:55 +0200, Jordi Espasa Clofent [EMAIL PROTECTED] wrote: 1) I do the sync process with csup(1); next I go into /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized kernels) and this file doesn't exists. You might like to check your CVSup site against http://www.mavetju.org/unix/freebsd-mirrors/ to confirm it is updating correctly. GENERIC should exist. * I reboot the machine (because of I suspect a very weird FS problem), boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) found and repair several errors. Epecially, one error claims my attention: SUPERBLOCK. It might have been useful if you had kept a record of the exact messages. If you repeat the fsck, does it now report any problems? If you are using an up-to-date CVSup mirror, my next suggestion would be hardware problems. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpOJlfwlwM25.pgp Description: PGP signature
Re: bad NFS/UDP performance
There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? Can you compare performanc with tcp? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 2008-09-26 at 10:04 +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? The scheduler has been changed to ULE, and NFS has historically been very sensitive to changes like that. You could try switching back to the 4BSD scheduler and seeing if that makes a difference. If it does, toggling PREEMPTION would also be interesting to see the results of. Gavin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and ISCSI, Strange Problem
Danny Braniss escreveu: I'm with a very strange problem in the FreeBSD 7.0R I use the iscsi_initiator to mount two devices of a Dell MD3000i, the file system is UFS. The problem occurs when I make a copy of a great directory for inside of the /data/email directory, passed some minutes of beginning of copy, the SSH connection stops to answer, when trying to open a new connection Password: it isn't requested, in the console, when typing the user root e to press enter, Password: also it isn't requested. The only way to come back is restarting the FreeBSD. When press CTRL+T during the freeze it is shown: # ssh [EMAIL PROTECTED] load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k In another freeze it showed state [ufs] During freeze, send and receive pings work fine, but no service runing work. I already verified for some related LOG, however not see nothing related. hi Daniel, the problem is probably that iscsi is deadlocked, so fetch ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gz cd /usr/src tar xpzf /path-to-tar-file/iscsi-2.1.tar.gz (cd sys/modules/iscsi/initiator; make; make install) (cd sbin/iscontrol;make; make install) probably the safest is now to reboot. Let me know what happens. obrigado (thanks?), danny Danny, You typed the ftp wrong. Obrigado, thanks !! =) Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? 1) Network card driver changes, could be, but at least iperf/tcp is ok - can't get udp numbers, do you know of any tool to measure udp performance? BTW, I also checked on different hardware, and the badness is there. According to INDEX, benchmarks/iperf does UDP bandwidth testing. I know, but I get about 1mgb, which seems somewhat low :-( benchmarks/nttcp should as well. What network card is in use? If Intel, what driver version (should be in dmesg). bge: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x9003 and bce: Broadcom NetXtreme II BCM5708 1000Base-T (B2) and intels, but haven't tested there yet. 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html gut feeling is that it's somewhere else: Writing 16 MB file BSCount / 7.0 --/ / 7.1 -/ 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s 64*512512 0.22s 71.45MB/s 0.45s 35.41MB/s 128*512256 0.21s 77.84MB/s 0.51s 31.34MB/s 256*512128 0.19s 82.47MB/s 0.43s 37.22MB/s 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s Average: 75.8633.00 the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in the measurements, but the relation are similar, good on 7.0, bad on 7.1 Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? no, but diffing the sysctl show: -vfs.nfs.realign_test: 22141777 +vfs.nfs.realign_test: 498351 -vfs.nfsrv.realign_test: 5005908 +vfs.nfsrv.realign_test: 0 +vfs.nfsrv.commit_miss: 0 +vfs.nfsrv.commit_blks: 0 changing them did nothing - or at least with respect to nfs throughput :-) danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, 2008-09-26 at 10:04 +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? The scheduler has been changed to ULE, and NFS has historically been very sensitive to changes like that. You could try switching back to the 4BSD scheduler and seeing if that makes a difference. If it does, toggling PREEMPTION would also be interesting to see the results of. Gavin I'm testing 7.0-stable vs 7.1-prerelease, and both have ULE. BTW, the nfs client hosts I'm testing are idle. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Major SMP problems with lstat/namei
On Friday 26 September 2008 05:20:14 am Dag-Erling Smørgrav wrote: Jeff Wheelhouse [EMAIL PROTECTED] writes: http://software.wheelhouse.org/rptest.tar.bz2 Thanks. I get similar results on head; vfs.lookup_shared actually seems to *reduce* performance by about 10% - 20%. I ran the test on both UFS and ZFS; there is no significant difference. You might try http://www.FreeBSD.org/~jhb/patches/namei_rwlock.patch However, it might also be useful in general to enable lock profiling and see which locks (if any) are contested. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Friday 26 September 2008 03:04:16 am Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? thanks, danny Perhaps use nfsstat to see if 7.1 is performing more on-the-wire requests? Also, if you can, do a binary search to narrow down when the regression occurred in RELENG_7. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, Sep 26, 2008 at 04:35:17PM +0300, Danny Braniss wrote: On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? 1) Network card driver changes, could be, but at least iperf/tcp is ok - can't get udp numbers, do you know of any tool to measure udp performance? BTW, I also checked on different hardware, and the badness is there. According to INDEX, benchmarks/iperf does UDP bandwidth testing. I know, but I get about 1mgb, which seems somewhat low :-( benchmarks/nttcp should as well. What network card is in use? If Intel, what driver version (should be in dmesg). bge: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x9003 and bce: Broadcom NetXtreme II BCM5708 1000Base-T (B2) and intels, but haven't tested there yet. Both bge(4) and bce(4) claim to support checksum offloading. You might try disabling it (ifconfig ... -txcsum -rxcsum) to see if things improve. If not, more troubleshooting is needed. You might also try turning off TSO if it's supported (check your ifconfig output for TSO in the options= section. Then use ifconfig ... -tso) Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? no, but diffing the sysctl show: -vfs.nfs.realign_test: 22141777 +vfs.nfs.realign_test: 498351 -vfs.nfsrv.realign_test: 5005908 +vfs.nfsrv.realign_test: 0 +vfs.nfsrv.commit_miss: 0 +vfs.nfsrv.commit_blks: 0 changing them did nothing - or at least with respect to nfs throughput :-) I'm not sure what any of these do, as NFS is a bit out of my league. :-) I'll be following this thread though! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and ISCSI, Strange Problem
the problem is probably that iscsi is deadlocked, so fetch ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gzs;/ftp/;/.cs.huji.ac.il; ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.1.tar.gz Danny, You typed the ftp wrong. hi Daniel, oh well, it was before coffee :-) Obrigado, thanks !! =) Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? 1) Network card driver changes, could be, but at least iperf/tcp is ok - can't get udp numbers, do you know of any tool to measure udp performance? BTW, I also checked on different hardware, and the badness is there. According to INDEX, benchmarks/iperf does UDP bandwidth testing. benchmarks/nttcp should as well. What network card is in use? If Intel, what driver version (should be in dmesg). 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html gut feeling is that it's somewhere else: Writing 16 MB file BSCount / 7.0 --/ / 7.1 -/ 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s 64*512512 0.22s 71.45MB/s 0.45s 35.41MB/s 128*512256 0.21s 77.84MB/s 0.51s 31.34MB/s 256*512128 0.19s 82.47MB/s 0.43s 37.22MB/s 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s Average: 75.8633.00 the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in the measurements, but the relation are similar, good on 7.0, bad on 7.1 Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? after more testing, it seems it's related to changes made between Aug 4 and Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try and close the gap. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
: -vfs.nfs.realign_test: 22141777 : +vfs.nfs.realign_test: 498351 : : -vfs.nfsrv.realign_test: 5005908 : +vfs.nfsrv.realign_test: 0 : : +vfs.nfsrv.commit_miss: 0 : +vfs.nfsrv.commit_blks: 0 : : changing them did nothing - or at least with respect to nfs throughput :-) : :I'm not sure what any of these do, as NFS is a bit out of my league. ::-) I'll be following this thread though! : :-- :| Jeremy Chadwickjdc at parodius.com | A non-zero nfs_realign_count is bad, it means NFS had to copy the mbuf chain to fix the alignment. nfs_realign_test is just the number of times it checked. So nfs_realign_test is irrelevant. it's nfs_realign_count that matters. Several things can cause NFS payloads to be improperly aligned. Anything from older network drivers which can't start DMA on a 2-byte boundary, resulting in the 14-byte encapsulation header causing improper alignment of the IP header payload, to rpc embedded in NFS TCP streams winding up being misaligned. Modern network hardware either support 2-byte-aligned DMA, allowing the encapsulation to be 2-byte aligned so the payload winds up being 4-byte aligned, or support DMA chaining allowing the payload to be placed in its own mbuf, or pad, etc. -- One thing I would check is to be sure a couple of nfsiod's are running on the client when doing your tests. If none are running the RPCs wind up being more synchronous and less pipelined. Another thing I would check is IP fragment reassembly statistics (for UDP) - there should be none for TCP connections no matter what the NFS I/O size selected. (It does seem more likely to be scheduler-related, though). -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regenerate ports tree from installed ports?
On Thu, 25 Sep 2008 23:25:46 +0200 Jordi Espasa Clofent [EMAIL PROTECTED] wrote: Hi all, I suppose it's a dumb (and crazy) question, but as post subject says: ¿Is it possible to regenerate the /usr/ports tree _from_ the installed ports? Possibly. If the installed ports were built from a consistent tree, you can always just use CVS to check out a copy of the ports tree for the date of the last port you installed. However, as was pointed out here, that doesn't mean you can actually build ports from them on an upgraded operating system. Until that point, it's all right. But everybody knows that you have to recompile all your installed ports after the kernel and userland upgrade, to re-link the new libraries and disappeared ones. Um, no, everyone doesn't know you need to do that. In fact, I've almost *never* been able to do that, because I've almost always had proprietary, binary-only software of some sort or another running on my boxes for which the vendor hadn't provided an appropriate update. That's what the compat libraries are for - you can install those, and just keep on running your old binaries. It's been a while, but I'm pretty sure I managed one update by doing the OS update - including compat - and then replacing the ports piecemeal while the old ones ran on the compat libraries. Of course, running on the compat libraries isn't the ideal solution, so you want to rebuild the ports if you can. Of course, the same thing applies to running old versions of the ports - you really want to get new bug fixes, security patches, and such like that may have come out since you installed the original software. But in my case, these boxes are used as shared web-hostings, and a lot of particularities are present. Change the php version, for example, can means that tens of webs not work fine. The solution in this case is to buy one new box, build the new version on it, including all ports, clone your customers environments to it, and start it as foobar-new. Tell your customers it's there, let them test things, help them fix what's needed, and after everyone is happy, swap the names. Repeat this process using the just-retired box to build the new one on. If these are inhouse services - so you can have some real down time - then I typically build a new system on a second disk with the same data directories, and test there. When it's all working, put everything on one disk, and then mirror the two disks, so it's there next time I need to do the dual boot upgrade thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
experimantal question about md's
Hallo @list, first please answer me directly, i be not on the list. Let us say i have a Machine with 8 CPUs and a lot of RAM. An i need a very high perfomance Storage for holding data. My idea was to setup a raid1(0) with virtual disk images. Created with mdconfig. My idea was to create minimum 2 md-diskimages, these are located fisrt one on the harddisk as type vnode second one as exact copy totally in the memory as type malloc For now the man-page mentoid me to not to do so, while large disks in RAM cause panics, and i know panics come surely Is the above scenario possible without panics? thanks a lot. greetings from sunny Germany michael -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
On Fri, Sep 26, 2008 at 04:35:17PM +0300, Danny Braniss wrote: I know, but I get about 1mgb, which seems somewhat low :-( Since UDP has no way to know how fast to send, you need to tell iperf how fast to send the packets. I think 1Mbps is the default speed. David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
popen() in multithreaded program - hangs?
I'm trying to write a client for the jack audio connection kit
(http://jackaudio.org), have hit an apparent bug and am not sure
who's at fault.
This is the client:
--
#include jack/jack.h
#include err.h
jack_port_t *input_port;
jack_port_t *output_port;
jack_client_t *client;
int
main (void)
{
jack_status_t status;
client = jack_client_open (cdemo, JackNoStartServer, status, default);
if (!client) errx (112, client_open: could not);
jack_client_close (client);
return 0;
}
--
The jack_client_open() call never returns and the process can only be killed
with SIGKILL. Tracing execution in gdb shows that the hang occurs in the
popen() call in jack_get_tmpdir(), defined at client.c:114:
http://trac.jackaudio.org/browser/trunk/jack/libjack/client.c
Is there a known issue with calling popen() in a multithreaded program? At
the point of that call, on my system, there are three running threads.
Any help/advice on how to resolve this problem would be appreciated.
xw
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad NFS/UDP performance
David, You beat me to it. Danny, read the iperf man page: -b, --bandwidth n[KM] set target bandwidth to n bits/sec (default 1 Mbit/sec). This setting requires UDP (-u). The page needs updating, though. It should read -b, --bandwidth n[KMG]. It also does NOT require -u. If you use -b, UDP is assumed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpOo3ttHcEYe.pgp Description: PGP signature
Re: popen() in multithreaded program - hangs?
[EMAIL PROTECTED] wrote:
I'm trying to write a client for the jack audio connection kit
(http://jackaudio.org), have hit an apparent bug and am not sure
what revision of FreeBSD?
who's at fault.
This is the client:
--
#include jack/jack.h
#include err.h
jack_port_t *input_port;
jack_port_t *output_port;
jack_client_t *client;
int
main (void)
{
jack_status_t status;
client = jack_client_open (cdemo, JackNoStartServer, status, default);
if (!client) errx (112, client_open: could not);
jack_client_close (client);
return 0;
}
--
The jack_client_open() call never returns and the process can only be killed
with SIGKILL. Tracing execution in gdb shows that the hang occurs in the
popen() call in jack_get_tmpdir(), defined at client.c:114:
http://trac.jackaudio.org/browser/trunk/jack/libjack/client.c
Is there a known issue with calling popen() in a multithreaded program? At
the point of that call, on my system, there are three running threads.
Any help/advice on how to resolve this problem would be appreciated.
xw
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
priority fields in a thread
Hello, I was wondering what all these different priority related fields in a thread structure meant. This is the 8.0 kernel tree. Thanks Ravi Td_base_pri Td_user_pri Td_base_user_pri Td_priority ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: popen() in multithreaded program - hangs?
On 20080926 16:43:37, Julian Elischer wrote: [EMAIL PROTECTED] wrote: I'm trying to write a client for the jack audio connection kit (http://jackaudio.org), have hit an apparent bug and am not sure what revision of FreeBSD? Ahem, should've mentioned that. FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC -- xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: popen() in multithreaded program - hangs?
On Sat, 27 Sep 2008, [EMAIL PROTECTED] wrote: On 20080926 16:43:37, Julian Elischer wrote: [EMAIL PROTECTED] wrote: I'm trying to write a client for the jack audio connection kit (http://jackaudio.org), have hit an apparent bug and am not sure what revision of FreeBSD? Ahem, should've mentioned that. FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC http://www.freebsd.org/releases/6.3R/errata.html http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: popen() in multithreaded program - hangs?
On 20080926 21:43:48, Daniel Eischen wrote: On Sat, 27 Sep 2008, [EMAIL PROTECTED] wrote: On 20080926 16:43:37, Julian Elischer wrote: [EMAIL PROTECTED] wrote: I'm trying to write a client for the jack audio connection kit (http://jackaudio.org), have hit an apparent bug and am not sure what revision of FreeBSD? Ahem, should've mentioned that. FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC http://www.freebsd.org/releases/6.3R/errata.html http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc I wonder if I'm missing something: $ sudo freebsd-update fetch Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 6.3-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 6.3-RELEASE-p4. I appear to have that update but the problem persists. -- xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: popen() in multithreaded program - hangs?
On Sat, 27 Sep 2008, [EMAIL PROTECTED] wrote: On 20080926 21:43:48, Daniel Eischen wrote: On Sat, 27 Sep 2008, [EMAIL PROTECTED] wrote: On 20080926 16:43:37, Julian Elischer wrote: [EMAIL PROTECTED] wrote: I'm trying to write a client for the jack audio connection kit (http://jackaudio.org), have hit an apparent bug and am not sure what revision of FreeBSD? Ahem, should've mentioned that. FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC http://www.freebsd.org/releases/6.3R/errata.html http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc I wonder if I'm missing something: $ sudo freebsd-update fetch Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 6.3-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 6.3-RELEASE-p4. I appear to have that update but the problem persists. It's not security related, so I don't know whether it would be in a binary update. You should follow the procedure listed in the links above. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
