From rpaulo at FreeBSD.org Tue Apr 1 04:10:10 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Tue Apr 1 04:10:15 2008 Subject: packet delay because of blackhole In-Reply-To: <1333421734.20080328201458@mail.ru> References: <1333421734.20080328201458@mail.ru> Message-ID: <20080401104128.GA1194@fnop.net> On Fri, Mar 28, 2008 at 08:14:58PM +0300, Anthony Pankov wrote: > Just for somebody convince. > > While analyzing client<->server HTTPS conversation one second delay in > packet exchange was discovered (strongly reproducible): > > Sample: > N time > 6 0.002303 10.28.4.14 10.28.4.50 SSL Client Hello > 7 0.106710 10.28.4.50 10.28.4.14 TCP 443 > 1447 [ACK] Seq=1 Ack=103 Win=65535 Len=0 > 8 1.045712 10.28.4.50 10.28.4.14 TLSv1 Server Hello, Certificate, Server Hello Done > > Another sample: > 10 0.011722 10.28.4.14 10.28.4.50 TLSv1 Application Data > 11 0.115933 10.28.4.50 10.28.4.14 TCP 443 > 1442 [ACK] Seq=839 Ack=519 Win=65466 Len=0 > 12 1.054037 10.28.4.50 10.28.4.14 TLSv1 Application Data > > The reason for delay is sysctl tcp.blackhole value grater than 0, much to surprise. > > So, turning tcp.blackhole to 0 eliminate any delay (strongly reproducible). > > System: FreeBSD 6_2_stable I'm not sure how performance penalty can induce a cache miss and I it's very processor specific. So, you're best guess is to profile the kernel. Regards, -- Rui Paulo From ap00 at mail.ru Tue Apr 1 07:03:49 2008 From: ap00 at mail.ru (Anthony Pankov) Date: Tue Apr 1 07:03:54 2008 Subject: packet delay because of blackhole In-Reply-To: <20080401104128.GA1194@fnop.net> References: <1333421734.20080328201458@mail.ru> <20080401104128.GA1194@fnop.net> Message-ID: <1493139437.20080401180529@mail.ru> Hello Rui, Tuesday, April 01, 2008, 2:41:29 PM, you wrote: RP> On Fri, Mar 28, 2008 at 08:14:58PM +0300, Anthony Pankov wrote: >> Just for somebody convince. >> >> While analyzing client<->server HTTPS conversation one second delay in >> packet exchange was discovered (strongly reproducible): >> >> Sample: >> N time >> 6 0.002303 10.28.4.14 10.28.4.50 SSL Client Hello >> 7 0.106710 10.28.4.50 10.28.4.14 TCP 443 > 1447 [ACK] Seq=1 Ack=103 Win=65535 Len=0 >> 8 1.045712 10.28.4.50 10.28.4.14 TLSv1 Server Hello, Certificate, Server Hello Done >> >> Another sample: >> 10 0.011722 10.28.4.14 10.28.4.50 TLSv1 Application Data >> 11 0.115933 10.28.4.50 10.28.4.14 TCP 443 > 1442 [ACK] Seq=839 Ack=519 Win=65466 Len=0 >> 12 1.054037 10.28.4.50 10.28.4.14 TLSv1 Application Data >> >> The reason for delay is sysctl tcp.blackhole value grater than 0, much to surprise. >> >> So, turning tcp.blackhole to 0 eliminate any delay (strongly reproducible). >> >> System: FreeBSD 6_2_stable RP> I'm not sure how performance penalty can induce a cache miss and I RP> it's very processor specific. So, you're best guess is to profile the RP> kernel. RP> Regards, I'm not fully understand what cache miss do you mean. I'll try to be more clear. During client<->server HTTPS conversation there is a packet delay (see "sample" and "Another sample") about 900 ms. Delay appear one per conversation in random place (between 7-8 packet in "sample", 11-12 in "another sample"). Of course, it's not depending from SSL session cache, SSL negotiation or any other apache/mod_ssl/OpenSSL setting/performance, otherwise i should write to another maillist. I have disabled all my sysctl tuning, one by one. No effect has achieved. But when i turn tcp.blackhole to zero, all things became fine. Maximum delay between packet is 6 ms. It is strange, so i've reported to all. I suggest to keep tcp.blackhole=0 and use firewall for protection. If one would raise tcp.blackhole value, than he should dump packets and make sure that there is no strange delay between packets. It most likely FreeBSD net issue. P.S. "Another sample" is not a sequel of "Sample", it is a dump of different transaction. -- Best regards, Anthony mailto:ap00@mail.ru From tom at tomjudge.com Tue Apr 1 21:51:46 2008 From: tom at tomjudge.com (Tom Judge) Date: Tue Apr 1 21:51:48 2008 Subject: Tuning: 100mbit faster, gbit slower. In-Reply-To: <200803241040.53346.josh@tcbug.org> References: <24adbbc00803231521h78844f26q77c48573f82408b9@mail.gmail.com> <200803240327.01211.josh@tcbug.org> <24adbbc00803240422m5b04b485s5df2f406aa89dc2b@mail.gmail.com> <200803241040.53346.josh@tcbug.org> Message-ID: <47F30B96.6000605@tomjudge.com> Josh Paetzel wrote: > > This is on RELENG_6_3 > > net.inet.tcp.sendspace=262144 > net.inet.tcp.recvspace=262144 > kern.ipc.maxsockbuf=1048576 > ifconfig em0 mtu 9014 (You'll need a switch that supports jumbo frames to do > this) > Daniel, you should note that all devices on your network also need to have the same MTU configured, and that Jumbo frames are only supported on gige connections so if you have any 100/10 devices you can not use jumbo frames. > iperf shows wire traffic around 969 mbps and FTP runs at 110 Megs/sec > scp/sftp appears to be cpu bound at 45 Megs/sec, and NFS with TCP mounts and > send/receive packets set to 16384 manages about 90 Megs/sec. > Hi Josh, If you are running SCP/SFTP over your internal lan and are not worried about the security of the data in the session only the authentication then you man want to check out the HPN patches for openssh (I belive they are available as an option in the openssh port) which re-enable the cypher 'none'. Also the latest patch set introduces multi threaded crypto so that ssh is not bound by the performance of a single cpu in multi cpu/core systems. We run the HPN patches here (the older set with no multi threading support) and we can saturate gige with a single scp/sftp/ssh connection between two reasonably spec'd boxes (Our mtu is 8192 as this is more compatiable with most hardware [nics and switchs] most of the hardware wie have will only do 9000 byte jumbo frames). Tom From bra at fsn.hu Thu Apr 3 13:01:59 2008 From: bra at fsn.hu (Attila Nagy) Date: Thu Apr 3 13:02:06 2008 Subject: Bad bind performance with FreeBSD 7 In-Reply-To: <479F02A7.9020607@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> Message-ID: <47F4D0DD.2040809@fsn.hu> On 01/29/08 11:40, Attila Nagy wrote: > ps: I have an other problem. I've recently switched from a last year > 6-STABLE to 7-STABLE and got pretty bad results on the same machine > with the same bind (9.4). > The graphs are here: > http://picasaweb.google.com/nagy.attila/20080129Fbsd6vs7Bind The problem still persists and now I can provide some profiling info, made by HWPMC. The samples were collected from totally equal machines, the only difference is the OS (FreeBSD 6-STABLE and FreeBSD 7-STABLE, amd64). Here is FreeBSD/amd64 6-STABLE (compiled yesterday): granularity: each sample hit covers 4 byte(s) for 0.00% of 158108.00 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 8.2 12909.00 12909.00 0 100.00% SHA256_Transform [1] 4.7 20408.00 7499.00 0 100.00% kern_select [2] 3.9 26594.00 6186.00 0 100.00% swi_net [3] 3.3 31829.00 5235.00 0 100.00% sopoll [4] 3.3 37059.00 5230.00 0 100.00% syscall [5] 3.3 42280.00 5221.00 0 100.00% bcopy [6] 3.2 47297.00 5017.00 0 100.00% critical_exit [7] 3.1 52274.00 4977.00 0 100.00% Xfast_syscall [8] 2.8 56748.00 4474.00 0 100.00% spinlock_exit [9] 2.8 61176.00 4428.00 0 100.00% DELAY [10] 2.5 65101.00 3925.00 0 100.00% netisr_poll [11] 2.1 68346.00 3245.00 0 100.00% bge_rxeof [12] 1.8 71126.00 2780.00 0 100.00% copyout [13] 1.7 73888.00 2762.00 0 100.00% _mtx_lock_sleep [14] 1.7 76641.00 2753.00 0 100.00% soreceive [15] 1.6 79245.00 2604.00 0 100.00% rn_match [16] 1.6 81769.00 2524.00 0 100.00% selrecord [17] 1.5 84187.00 2418.00 0 100.00% netisr_pollmore [18] 1.5 86526.00 2339.00 0 100.00% copyin [19] 1.5 88843.00 2317.00 0 100.00% uma_zfree_arg [20] 1.4 91011.00 2168.00 0 100.00% uma_zalloc_arg [21] 1.3 93118.00 2107.00 0 100.00% soo_poll [22] 1.1 94793.00 1675.00 0 100.00% bge_poll [23] 1.0 96428.00 1635.00 0 100.00% spinlock_enter [24] And here is FreeBSD/amd64 7-STABLE (also compiled yesterday): granularity: each sample hit covers 4 byte(s) for 0.00% of 204813.00 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 9.5 19395.00 19395.00 0 100.00% _mtx_lock_sleep [1] 7.1 33844.00 14449.00 0 100.00% SHA256_Transform [2] 4.2 42408.00 8564.00 0 100.00% DELAY [3] 3.5 49583.00 7175.00 0 100.00% kern_select [4] 3.4 56565.00 6982.00 0 100.00% syscall [5] 3.2 63104.00 6539.00 0 100.00% sopoll_generic [6] 2.9 69125.00 6021.00 0 100.00% Xfast_syscall [7] 2.7 74615.00 5490.00 0 100.00% bcopy [8] 2.6 79947.00 5332.00 0 100.00% swi_net [9] 2.2 84515.00 4568.00 0 100.00% critical_exit [10] 1.9 88438.00 3923.00 0 100.00% netisr_poll [11] 1.8 92179.00 3741.00 0 100.00% spinlock_exit [12] 1.8 95882.00 3703.00 0 100.00% copyout [13] 1.7 99343.00 3461.00 0 100.00% _thread_lock_flags [14] 1.6 102581.00 3238.00 0 100.00% uma_zfree_arg [15] 1.4 105358.00 2777.00 0 100.00% spinlock_enter [16] 1.2 107897.00 2539.00 0 100.00% rn_match [17] 1.2 110369.00 2472.00 0 100.00% soreceive_generic [18] 1.2 112814.00 2445.00 0 100.00% intr_event_schedule_thread [19] 1.2 115194.00 2380.00 0 100.00% uma_zalloc_arg [20] 1.1 117417.00 2223.00 0 100.00% netisr_pollmore [21] 1.0 119444.00 2027.00 0 100.00% selrecord [22] 1.0 121450.00 2006.00 0 100.00% copyin [23] 1.0 123397.00 1947.00 0 100.00% cpu_switch [24] Here are the full output: http://people.fsn.hu/~bra/freebsd/bind94-performance-fbsd6vs7-20080403/ At first glimpse it seems that there is a lot more time spent in _mtx_lock_sleep in FreeBSD 7 than in FreeBSD 6... -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From stefan.lambrev at moneybookers.com Thu Apr 3 13:22:04 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu Apr 3 13:22:08 2008 Subject: Bad bind performance with FreeBSD 7 In-Reply-To: <47F4D0DD.2040809@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47F4D0DD.2040809@fsn.hu> Message-ID: <47F4D9F2.9070200@moneybookers.com> Greetings, Attila Nagy wrote: > On 01/29/08 11:40, Attila Nagy wrote: >> ps: I have an other problem. I've recently switched from a last year >> 6-STABLE to 7-STABLE and got pretty bad results on the same machine >> with the same bind (9.4). >> The graphs are here: >> http://picasaweb.google.com/nagy.attila/20080129Fbsd6vs7Bind > The problem still persists and now I can provide some profiling info, > made by HWPMC. > > Sorry if you already answer this question, but at least I can find it in the thread. What scheduler are you using on RELENG_7 ? Did you check with both schedulers (ule/4bsd) to see which one works better for you? Also are you sure that you service the same number of requests - I see that the 6.x image shows CPU usage from Aug 2007 and 7.x image is from Jan 2008 ... is it possible, that you have more requests and that's why your CPU usage increased? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From bra at fsn.hu Thu Apr 3 13:54:54 2008 From: bra at fsn.hu (Attila Nagy) Date: Thu Apr 3 13:55:00 2008 Subject: Bad bind performance with FreeBSD 7 In-Reply-To: <47F4D9F2.9070200@moneybookers.com> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47F4D0DD.2040809@fsn.hu> <47F4D9F2.9070200@moneybookers.com> Message-ID: <47F4E1A1.2020500@fsn.hu> On 2008.04.03. 15:21, Stefan Lambrev wrote: > Greetings, > > Attila Nagy wrote: >> On 01/29/08 11:40, Attila Nagy wrote: >>> ps: I have an other problem. I've recently switched from a last year >>> 6-STABLE to 7-STABLE and got pretty bad results on the same machine >>> with the same bind (9.4). >>> The graphs are here: >>> http://picasaweb.google.com/nagy.attila/20080129Fbsd6vs7Bind >> The problem still persists and now I can provide some profiling info, >> made by HWPMC. >> >> > Sorry if you already answer this question, but at least I can find it > in the thread. > What scheduler are you using on RELENG_7 ? > Did you check with both schedulers (ule/4bsd) to see which one works > better for you? > Also are you sure that you service the same number of requests - I see > that the 6.x image shows CPU usage from > Aug 2007 and 7.x image is from Jan 2008 ... is it possible, that you > have more requests and that's why your CPU usage increased? As for the pictures: GENERIC kernels, so 4BSD on both versions (6 and 7). As for the profiling info: 4BSD on 6, ULE on 7 (because both were upgraded yesterday, and ULE is now default in RELENG_7) The pictures are from the same timeframe (what aug 2007 refers to is the time when the OS was compiled), the two machines were behind a per packet load balancer, so yes: at least in pps, they've got exactly the same traffic (of course it was possible be that one machine could serve the answer directly from the cache, while the other had to go out, but I've started them at the same time, so I think this effect was minimized). From bra at fsn.hu Thu Apr 3 15:22:49 2008 From: bra at fsn.hu (Attila Nagy) Date: Thu Apr 3 15:22:53 2008 Subject: max-cache-size doesn't work with 9.5.0b1 In-Reply-To: References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> Message-ID: <47F4F63E.80703@fsn.hu> Sorry again for the long delay, I've got other work to do, and our 9.4 servers work fine (at least on FreeBSD 6, though, see the other -performance- problem)... On 02/20/08 04:30, JINMEI Tatuya / ???? wrote: > At Tue, 19 Feb 2008 14:59:15 +0100, > Attila Nagy wrote: > > >>> Okay, then please try this patch with '-n 1' (note: this patch doesn't >>> contain the memory statistics hack via the HTTP interface, but I don't >>> we don't need it for this test). >>> > > [...] > > >> (max-cache-size still 32M) >> > > Hmm, then the mutex locks dynamically generated are also irrelevant. > > I've also tried to reproduce the problem in a similar environment > (BIND 9.5.0b1 with threads on FreeBSD 7.0RC1/AMD64, cache-only > configuration, using a real query sample), unsuccessfully. One > significant difference is that I disabled SMP in the kernel (it was > very unstable with the SMP support for some unknown reason), but I > doubt this is the key for the difference of the named behavior. > I don't know why am I the only one to see this. > BTW, is this reproduceable on FreeBSD 6.x? If so, then I'd like to > see what happens if you specify some small value of datasize > (e.g. 512MB) and have named abort when malloc() fails with the "X" > _malloc_options. (This option doesn't seem to work for FreeBSD 7.x, > at least at the moment). > Yes, it's the same, even when there is a different (libpthreads, KSE) threading library is in use. I've recompiled named with the following in main(): ./work/bind-9.5.0b2/bin/named/main.c: _malloc_options="X"; And set cache-size to 32MB. At: 21664 bind 4 20 0 819M 819M kserel 0 5:32 0.00% named.950 I pressed a CTRL-C: mem.c:1114: REQUIRE((((ctx) != ((void *)0)) && (((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C')))))) failed. > Some other questions: > - can we see your named.conf? If you specify non-default > configuration options, that might be the reason for, or related to, > this problem. > Of course (see at the end). > - does your named produce lot of log messages? If so, it might also > be a reason (simply because it relies on standard libraries). > grep named ns20080403.log | wc -l 1930006 For today (17 hours and 18 minutes of logs). Is this a lot? Config (normally max-cache-size is about 2400M): -hmm I haven't tried to change cleaning-interval, it was needed because the default cache housekeeping effectively stopped the ns during the cleanup- options { directory "/etc/bind"; tcp-clients 256; recursive-clients 8192; max-cache-size 32M; minimal-responses yes; pid-file "/var/run/named.pid"; cleaning-interval 15; allow-query-cache { any; }; allow-query { any; }; allow-recursion { any; }; }; controls { inet * port 953 allow { } keys { "rndc-key"; }; }; key "rndc-key" { algorithm hmac-md5; secret }; logging { channel syslog-ng { syslog local5; severity info; print-category yes; print-severity yes; }; category default { syslog-ng; }; category config { syslog-ng; }; category xfer-in { syslog-ng; }; category xfer-out { syslog-ng; }; category notify { syslog-ng; }; category security { syslog-ng; }; category update { syslog-ng; }; category lame-servers { syslog-ng; }; category update-security { syslog-ng; }; }; zone "10.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "16.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "17.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "18.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "19.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "20.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "21.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "22.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "23.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "24.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "25.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "26.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "27.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "28.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "29.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "30.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "31.172.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; zone "168.192.in-addr.arpa" in { type master; file "db/db.rfc1918"; }; -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From Jinmei_Tatuya at isc.org Thu Apr 3 17:46:54 2008 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Thu Apr 3 18:09:28 2008 Subject: max-cache-size doesn't work with 9.5.0b1 In-Reply-To: <47F4F63E.80703@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> <47F4F63E.80703@fsn.hu> Message-ID: At Thu, 03 Apr 2008 17:22:38 +0200, Attila Nagy wrote: > Sorry again for the long delay, I've got other work to do, and our 9.4 > servers work fine (at least on FreeBSD 6, though, see the other > -performance- problem)... No problem, I understand testing a beta version cannot be a high priority work. > > BTW, is this reproduceable on FreeBSD 6.x? If so, then I'd like to > > see what happens if you specify some small value of datasize > > (e.g. 512MB) and have named abort when malloc() fails with the "X" > > _malloc_options. (This option doesn't seem to work for FreeBSD 7.x, > > at least at the moment). > > > Yes, it's the same, even when there is a different (libpthreads, KSE) > threading library is in use. > I've recompiled named with the following in main(): > ./work/bind-9.5.0b2/bin/named/main.c: _malloc_options="X"; > > And set cache-size to 32MB. > > At: > 21664 bind 4 20 0 819M 819M kserel 0 5:32 0.00% named.950 > I pressed a CTRL-C: > mem.c:1114: REQUIRE((((ctx) != ((void *)0)) && (((const isc__magic_t > *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C')))))) > failed. Hmm, this is odd in two points: 1. the "X" malloc option doesn't seem to work as expected. I expected a call to malloc() should trigger an assertion failure (within the malloc library) at a much earlier stage. Does it change if you try the alternative debugging approach I mentioned before? That is: - create a symbolic link from "/etc/malloc.conf" to "X": # ln -s X /etc/malloc.conf - start named with a moderate limitation of virtual memory size, e.g. # /usr/bin/limits -v 384m $path_to_named/named 2. Whether it's related to this max-cache-size issue, the assertion failure in mem.c wasn't an expected result; this is likely to be a bug anyway. If the process dumped a core, can you show the stack backtrace of it? (gdb) thread apply all bt full > > Some other questions: > > - can we see your named.conf? If you specify non-default > > configuration options, that might be the reason for, or related to, > > this problem. > > > Of course (see at the end). > > > - does your named produce lot of log messages? If so, it might also > > be a reason (simply because it relies on standard libraries). > > > grep named ns20080403.log | wc -l > 1930006 > For today (17 hours and 18 minutes of logs). > Is this a lot? This means about 31 log messages per second. This may not be extremely frequent, but if some memory is lost for every log message, I guess it could be a reason for the growing memory at the hight rate we've seen. What if you change the channel setting from: > channel syslog-ng { > syslog local5; > severity info; > print-category yes; > print-severity yes; > }; to this one? channel syslog-ng { null; severity info; print-category yes; print-severity yes; }; BTW, > -hmm I haven't tried to change cleaning-interval, it was needed because > the default cache housekeeping effectively stopped the ns during the > cleanup- This doesn't matter for 9.5. It doesn't perform periodic cleaning regardless of the value of cleaning-interval. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From fw at deneb.enyo.de Fri Apr 4 12:44:27 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri Apr 4 13:14:39 2008 Subject: max-cache-size doesn't work with 9.5.0b1 In-Reply-To: ("JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJ?= "'s message of "Wed, 20 Feb 2008 13:51:02 -0800") References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> Message-ID: <87abk9yelm.fsf@mid.deneb.enyo.de> * JINMEI Tatuya / ????: > Then the named process will eventually abort itself with a core dump > due to malloc failure. Please show us the stack trace at that point. > Hopefully it will reveal the malloc call that keeps consuming memory. I've successfully used a backtrace()-instrumented malloc() to track down difficult memory leaks. backtrace() is necessary because it allows you to see past malloc() wrappers. (backtrace() seems to be part of libexecinfo on FreeBSD.) From kris at FreeBSD.org Fri Apr 4 13:31:52 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Apr 4 13:32:00 2008 Subject: Bad bind performance with FreeBSD 7 In-Reply-To: <47F4E1A1.2020500@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47F4D0DD.2040809@fsn.hu> <47F4D9F2.9070200@moneybookers.com> <47F4E1A1.2020500@fsn.hu> Message-ID: <47F62DC5.5010703@FreeBSD.org> Attila Nagy wrote: > On 2008.04.03. 15:21, Stefan Lambrev wrote: >> Greetings, >> >> Attila Nagy wrote: >>> On 01/29/08 11:40, Attila Nagy wrote: >>>> ps: I have an other problem. I've recently switched from a last year >>>> 6-STABLE to 7-STABLE and got pretty bad results on the same machine >>>> with the same bind (9.4). >>>> The graphs are here: >>>> http://picasaweb.google.com/nagy.attila/20080129Fbsd6vs7Bind >>> The problem still persists and now I can provide some profiling info, >>> made by HWPMC. >>> >>> >> Sorry if you already answer this question, but at least I can find it >> in the thread. >> What scheduler are you using on RELENG_7 ? >> Did you check with both schedulers (ule/4bsd) to see which one works >> better for you? >> Also are you sure that you service the same number of requests - I see >> that the 6.x image shows CPU usage from >> Aug 2007 and 7.x image is from Jan 2008 ... is it possible, that you >> have more requests and that's why your CPU usage increased? > As for the pictures: GENERIC kernels, so 4BSD on both versions (6 and 7). > As for the profiling info: 4BSD on 6, ULE on 7 (because both were > upgraded yesterday, and ULE is now default in RELENG_7) > > The pictures are from the same timeframe (what aug 2007 refers to is the > time when the OS was compiled), the two machines were behind a per > packet load balancer, so yes: at least in pps, they've got exactly the > same traffic (of course it was possible be that one machine could serve > the answer directly from the cache, while the other had to go out, but > I've started them at the same time, so I think this effect was minimized). User time is much greater so named is doing much more work for some reason. It doesn't appear that this is a kernel problem. Verify that the config is identical, and you are not overloading it (bind doesn't scale beyond 4 threads). Kris From bra at fsn.hu Fri Apr 4 14:34:56 2008 From: bra at fsn.hu (Attila Nagy) Date: Fri Apr 4 14:35:02 2008 Subject: max-cache-size doesn't work with 9.5.0b1 In-Reply-To: References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> <47F4F63E.80703@fsn.hu> Message-ID: <47F63C82.7060502@fsn.hu> On 04/03/08 19:46, JINMEI Tatuya / ???? wrote: > Hmm, this is odd in two points: > 1. the "X" malloc option doesn't seem to work as expected. I expected > a call to malloc() should trigger an assertion failure (within the > malloc library) at a much earlier stage. Does it change if you try > the alternative debugging approach I mentioned before? That is: > - create a symbolic link from "/etc/malloc.conf" to "X": > # ln -s X /etc/malloc.conf > - start named with a moderate limitation of virtual memory size, e.g. > # /usr/bin/limits -v 384m $path_to_named/named > > 2. Whether it's related to this max-cache-size issue, the assertion > failure in mem.c wasn't an expected result; this is likely to be a > bug anyway. If the process dumped a core, can you show the > stack backtrace of it? > (gdb) thread apply all bt full > > No effect, the process grows happily. I don't have a core dump. > This means about 31 log messages per second. This may not be > extremely frequent, but if some memory is lost for every log message, > I guess it could be a reason for the growing memory at the hight rate > we've seen. > > What if you change the channel setting from: > > I've added this, so now the server doesn't log much (after start, noting): category default { null; }; The memory usage still grows. -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From Jinmei_Tatuya at isc.org Fri Apr 4 17:12:01 2008 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Fri Apr 4 17:55:59 2008 Subject: max-cache-size doesn't work with 9.5.0b1 In-Reply-To: <47F63C82.7060502@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> <47F4F63E.80703@fsn.hu> <47F63C82.7060502@fsn.hu> Message-ID: At Fri, 04 Apr 2008 16:34:42 +0200, Attila Nagy wrote: > No effect, the process grows happily. I don't have a core dump. Hmm, sorry, then I have no further idea of chasing the problem. A few points that may help: - can you show the diff you applied to bin/named/main.c when you added the malloc_options? - regarding the core dump, you may have to set the "kern.sugid_coredump" sysctl variable to 1, and make sure that then directly where named resides (which should be under /etc/bind/ with your config) is writable for the uid of the process. Or, simply run named as a root without specifying -u for the debugging purpose. - is it possible for me to get access to the test machine, or to get the query pattern so that I can reproduce the problem by myself? As I stated before, I tried to reproduce it with my box that has the similar system environment, but I failed to see the problem. Thanks, --- JINMEI, Tatuya Internet Systems Consortium, Inc. From ivoras at freebsd.org Fri Apr 11 12:13:54 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Apr 11 12:14:01 2008 Subject: IO Scheduling Message-ID: I found an interesting post: http://thread.gmane.org/gmane.comp.db.postgresql.performance/15979 By itself the post doesn't say anything specific, except that apparently great improvements can be gained on some loads with different IO scheduling policies on Linux. It's maybe something to take into account when comparing performance to Linux. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080411/9b30e956/signature.pgp From ari at ish.com.au Fri Apr 11 23:36:05 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Fri Apr 11 23:36:11 2008 Subject: 10GbE speeds Message-ID: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> I have a project with 3 workstations all needing high speed access to about 6Tb of storage. In the past I've installed technology such as fibre channel connected SAN storage (using Apple's xsan) for up to a dozen workstations, but with only three workstations for this project I'm thinking about 10GbE. The workstations will be OSX and the server FreeBSD 7 with a bunch of disks in a RAID 5 or RAID 10 configuration. Are 10GbE NICs and drivers significantly mature enough under FreeBSD to accomplish this? I'd need to achieve about 60MB/s transfer rate which is theoretically quite doable, as long as the drive array can keep up with three streams of that speed. I'd use netatalk, samba or nfs to share files depending on which I can eek the best speeds out of. Alternatively I could populate the server with 1GbE NICs, one per workstation and use cross over cable. That way there is absolutely no contention on the network. Any thoughts about the viability of this? Is 10GbE in production use with FreeBSD and does it scale well? Cheers Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From kip.macy at gmail.com Sat Apr 12 00:04:02 2008 From: kip.macy at gmail.com (Kip Macy) Date: Sat Apr 12 00:04:07 2008 Subject: 10GbE speeds In-Reply-To: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> Message-ID: > Any thoughts about the viability of this? Is 10GbE in production use with > FreeBSD and does it scale well? It seems reasonable to me. Vendors are shipping products with some flavor of freebsd with cxgb and mxge and products are planned for ixgbe. -Kip > > > Cheers > Ari Maniatis > > > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > From Muhammad.Shafiq at neterion.com Sat Apr 12 05:05:42 2008 From: Muhammad.Shafiq at neterion.com (Muhammad Shafiq) Date: Sat Apr 12 05:05:49 2008 Subject: 10GbE speeds In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77035EDB26@nekter> References: <78C9135A3D2ECE4B8162EBDCE82CAD77035EDB26@nekter> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77035EDB5C@nekter> Neterion is shipping 10G (XFRAME series) adapters, along with FreeBSD driver ("nxge"), for quite some time. Please refer to http://www.neterion.com/support/xframe_customers.html for latest FreeBSD driver(s) and other support info. Shafiq -----Original Message----- From: owner-freebsd-performance@freebsd.org [mailto:owner-freebsd-performance@freebsd.org] On Behalf Of Kip Macy Sent: Friday, April 11, 2008 4:40 PM To: Aristedes Maniatis Cc: freebsd-performance@freebsd.org Subject: Re: 10GbE speeds > Any thoughts about the viability of this? Is 10GbE in production use with > FreeBSD and does it scale well? It seems reasonable to me. Vendors are shipping products with some flavor of freebsd with cxgb and mxge and products are planned for ixgbe. -Kip > > > Cheers > Ari Maniatis > > > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" From gnn at freebsd.org Tue Apr 15 13:08:48 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Apr 15 13:08:54 2008 Subject: 10GbE speeds In-Reply-To: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> Message-ID: At Sat, 12 Apr 2008 09:08:13 +1000, Aristedes Maniatis wrote: > > I have a project with 3 workstations all needing high speed access to > about 6Tb of storage. In the past I've installed technology such as > fibre channel connected SAN storage (using Apple's xsan) for up to a > dozen workstations, but with only three workstations for this project > I'm thinking about 10GbE. The workstations will be OSX and the server > FreeBSD 7 with a bunch of disks in a RAID 5 or RAID 10 configuration. > > Are 10GbE NICs and drivers significantly mature enough under FreeBSD > to accomplish this? I'd need to achieve about 60MB/s transfer rate > which is theoretically quite doable, as long as the drive array can > keep up with three streams of that speed. I'd use netatalk, samba or > nfs to share files depending on which I can eek the best speeds out of. > > Alternatively I could populate the server with 1GbE NICs, one per > workstation and use cross over cable. That way there is absolutely no > contention on the network. > > Any thoughts about the viability of this? Is 10GbE in production use > with FreeBSD and does it scale well? I am working with the Chelsio hardware and it seems to be well supported on FreeBSD. All the machines in that system are FreeBSD though. How do you intend to get the OSX systems to be 10GE? Best, George From ari at ish.com.au Wed Apr 16 00:02:35 2008 From: ari at ish.com.au (Aristedes Maniatis) Date: Wed Apr 16 00:02:42 2008 Subject: 10GbE speeds In-Reply-To: References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> Message-ID: <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> On 15/04/2008, at 10:54 PM, gnn@freebsd.org wrote: > I am working with the Chelsio hardware and it seems to be well > supported on FreeBSD. All the machines in that system are FreeBSD > though. How do you intend to get the OSX systems to be 10GE? What sort of throughput are you getting with that setup? Are you using NFS between the systems? Good question about OSX, and I hadn't got to that part yet :-) But I was hoping that some OSX drivers existed. My fail back plan is to put 3 x 1GbE NICs into the server and just use crossover cable between the 3 workstations and the server to avoid any contention within the ethernet network. Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From kip.macy at gmail.com Wed Apr 16 00:09:06 2008 From: kip.macy at gmail.com (Kip Macy) Date: Wed Apr 16 00:09:10 2008 Subject: 10GbE speeds In-Reply-To: <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> Message-ID: Myricom has OS X support, Chelsio has support in the works. I don't know about Neterion or Intel. -Kip On 4/15/08, Aristedes Maniatis wrote: > > On 15/04/2008, at 10:54 PM, gnn@freebsd.org wrote: > > I am working with the Chelsio hardware and it seems to be well > > supported on FreeBSD. All the machines in that system are FreeBSD > > though. How do you intend to get the OSX systems to be 10GE? > > > What sort of throughput are you getting with that setup? Are you using > NFS between the systems? > > Good question about OSX, and I hadn't got to that part yet :-) But I > was hoping that some OSX drivers existed. My fail back plan is to put > 3 x 1GbE NICs into the server and just use crossover cable between the > 3 workstations and the server to avoid any contention within the > ethernet network. > > Ari Maniatis > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > From bmeekhof at umich.edu Wed Apr 16 00:17:11 2008 From: bmeekhof at umich.edu (Benjeman J. Meekhof) Date: Wed Apr 16 00:17:18 2008 Subject: 10GbE speeds In-Reply-To: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> Message-ID: <48054577.2050902@umich.edu> Hi Aristedes, We are/were testing FreeBSD on a Dell PE2950 with a Myricom 10GB PCI-Express copper CX card. The driver seems mature. In tests out of the box, I only saw about 3Gbps from iperf (testing against a linux system...and maybe there are other issues with our environment/that system to tune up yet...i wouldn't take that number too seriously). I think some tuning could get it up to the maximum, anyways. It certainly took a little work to get our Linux systems up to the max, so I would say that in general the defaults with 10G drivers on any system need some work to hit the maximum bandwidth. -Ben Aristedes Maniatis wrote: > I have a project with 3 workstations all needing high speed access to > about 6Tb of storage. In the past I've installed technology such as > fibre channel connected SAN storage (using Apple's xsan) for up to a > dozen workstations, but with only three workstations for this project > I'm thinking about 10GbE. The workstations will be OSX and the server > FreeBSD 7 with a bunch of disks in a RAID 5 or RAID 10 configuration. > > Are 10GbE NICs and drivers significantly mature enough under FreeBSD to > accomplish this? I'd need to achieve about 60MB/s transfer rate which is > theoretically quite doable, as long as the drive array can keep up with > three streams of that speed. I'd use netatalk, samba or nfs to share > files depending on which I can eek the best speeds out of. > > Alternatively I could populate the server with 1GbE NICs, one per > workstation and use cross over cable. That way there is absolutely no > contention on the network. > > Any thoughts about the viability of this? Is 10GbE in production use > with FreeBSD and does it scale well? > > > Cheers > Ari Maniatis > > > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > > -- Benjeman Meekhof - UM ATLAS/AGLT2 Computing office: 734-764-3450 cell: 734-417-6312 From bmeekhof at umich.edu Wed Apr 16 00:31:16 2008 From: bmeekhof at umich.edu (Benjeman J. Meekhof) Date: Wed Apr 16 00:31:21 2008 Subject: ZFS, Dell PE2950 Message-ID: <480548CF.5080104@umich.edu> Hi, I posted earlier about some results with this same system using UFS2. Now trying to test ZFS. This is a Dell PE2950 with two Perc6 controllers and 4 md1000 disk shelves with 750GB drives. 16GB RAM, dual quad core Xeon. I recompiled our kernel to use the ULE scheduler instead of default. I could not get through an entire run of iozone without a system reboot/crash. ZFS is clearly labeled experimental, of course. It seems to die for sure around 10 processes, sometimes less (this is the end of my output from iozone): Children see throughput for 10 readers = 135931.72 KB/sec Parent sees throughput for 10 readers = 135927.24 KB/sec Min throughput per process = 13351.26 KB/sec Max throughput per process = 14172.05 KB/sec Avg throughput per process = 13593.17 KB/sec Min xfer = 31586816.00 KB Some zpool info below - each volume below is a raid6 of 30PD on one controller. I may try different hardware volume configs for fun. zpool create test mfid0 mfid2 # pool is automatically mounted at /test # pool: test # state: ONLINE # scrub: none requested #config: # # NAME STATE READ WRITE CKSUM # test ONLINE 0 0 0 # mfid0 ONLINE 0 0 0 # mfid2 ONLINE 0 0 0 # #errors: No known data errors -Ben From swmspam at swmoore.net Wed Apr 16 05:07:08 2008 From: swmspam at swmoore.net (Stephen Moore) Date: Wed Apr 16 05:07:13 2008 Subject: Tweaking Disk Cache/Buffers and fsync Message-ID: <001101c89f7b$fc626600$c3cb2ed0@d400> There's a lot of discussion on the sysctl settings for vfs disk cache/buffers, but very little consolidated or comprehensive explanations. I have a NAS box with 1GB of memory, but rarely see over ~40MB of utilization during file transfers. When writing a large file to the NAS, I see the transfer rate throttle and pause in regular intervals. This indicates to me the dirty buffers are flushing and writing to the disk, and the file transfer is interrupted during the disk write process. Therefore, I would like to (1) increase the memory utilization, so that a large file write (500MB) will buffer entirely to memory for fastest transfer speeds, and (2) then take as long as needed to write the dirty buffers to the disk, after the transfer is concluded. For part (1), I looked at the following sysctl settings, but I don't fully understand the interactions: vfs.maxbufspace vfs.lobufspace vfs.hibufspace vfs.hidirtybuffers vfs.hirunningspace also /boot/loader.conf kern.nbuf I understand some rules: hirunningspace should be between 1MB to 4MB. lobufspace should be 25% to 75% of hibufspace. What I don't understand is the relationship between maxbufspace and hibufspace, and what are good values. I also don't understand hidirtybuffers. For part (2), I need to slow down the occurrence of sync() or fsync(). Ideally, a sync would not occur for 300 seconds, which is about 10 times as long as (apparently) the default setting. (obviously, if the buffer space is full, a sync would need to occur to make more room.) I've seen references of a daemon to periodically run a sync, or is it controlled by init? Yes, this increases vulnerability when the data is in buffer before committed to disk, but in my application, this is reasonable. From gnn at freebsd.org Wed Apr 16 07:31:06 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Wed Apr 16 07:31:12 2008 Subject: 10GbE speeds In-Reply-To: <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> Message-ID: At Wed, 16 Apr 2008 10:02:33 +1000, Aristedes Maniatis wrote: > > > On 15/04/2008, at 10:54 PM, gnn@freebsd.org wrote: > > I am working with the Chelsio hardware and it seems to be well > > supported on FreeBSD. All the machines in that system are FreeBSD > > though. How do you intend to get the OSX systems to be 10GE? > > > What sort of throughput are you getting with that setup? Are you using > NFS between the systems? I haven't done any performance testing of bandwidth as yet and we are not using these for NFS. > Good question about OSX, and I hadn't got to that part yet :-) But I > was hoping that some OSX drivers existed. My fail back plan is to > put 3 x 1GbE NICs into the server and just use crossover cable > between the 3 workstations and the server to avoid any contention > within the ethernet network. I think you want either a pure 10GbE network or a pure 1GbE network because my understanding is that 10GbE switches have issues with mixed links. I have not tested that first hand yet though. Best, George From stefan.lambrev at moneybookers.com Wed Apr 16 07:43:24 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Wed Apr 16 07:43:32 2008 Subject: 10GbE speeds In-Reply-To: <48054577.2050902@umich.edu> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> <48054577.2050902@umich.edu> Message-ID: <4805AE0D.1050005@moneybookers.com> Greetings, Benjeman J. Meekhof wrote: > Hi Aristedes, > > We are/were testing FreeBSD on a Dell PE2950 with a Myricom 10GB > PCI-Express copper CX card. The driver seems mature. In tests out of > the box, I only saw about 3Gbps from iperf (testing against a linux > system...and maybe there are other issues with our environment/that > system to tune up yet...i wouldn't take that number too seriously). If I remember correctly there is a problem with iperf, because it utilize too much CPU. I saw patches flying around, and part of them are in FreeBSD ports collection I think. Personally I prefer netperf for doing network tests :) > > I think some tuning could get it up to the maximum, anyways. It > certainly took a little work to get our Linux systems up to the max, > so I would say that in general the defaults with 10G drivers on any > system need some work to hit the maximum bandwidth. > > -Ben > > Aristedes Maniatis wrote: >> I have a project with 3 workstations all needing high speed access to >> about 6Tb of storage. In the past I've installed technology such as >> fibre channel connected SAN storage (using Apple's xsan) for up to a >> dozen workstations, but with only three workstations for this project >> I'm thinking about 10GbE. The workstations will be OSX and the server >> FreeBSD 7 with a bunch of disks in a RAID 5 or RAID 10 configuration. >> >> Are 10GbE NICs and drivers significantly mature enough under FreeBSD >> to accomplish this? I'd need to achieve about 60MB/s transfer rate >> which is theoretically quite doable, as long as the drive array can >> keep up with three streams of that speed. I'd use netatalk, samba or >> nfs to share files depending on which I can eek the best speeds out of. >> >> Alternatively I could populate the server with 1GbE NICs, one per >> workstation and use cross over cable. That way there is absolutely no >> contention on the network. >> >> Any thoughts about the viability of this? Is 10GbE in production use >> with FreeBSD and does it scale well? >> >> >> Cheers >> Ari Maniatis >> >> >> >> >> --------------------------> >> ish >> http://www.ish.com.au >> Level 1, 30 Wilson Street Newtown 2042 Australia >> phone +61 2 9550 5001 fax +61 2 9550 4001 >> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >> >> >> _______________________________________________ >> freebsd-performance@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-performance >> To unsubscribe, send any mail to >> "freebsd-performance-unsubscribe@freebsd.org" >> >> > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From ivoras at freebsd.org Wed Apr 16 08:57:50 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 16 08:57:57 2008 Subject: ZFS, Dell PE2950 In-Reply-To: <480548CF.5080104@umich.edu> References: <480548CF.5080104@umich.edu> Message-ID: Benjeman J. Meekhof wrote: > Hi, > > I posted earlier about some results with this same system using UFS2. > Now trying to test ZFS. This is a Dell PE2950 with two Perc6 > controllers and 4 md1000 disk shelves with 750GB drives. 16GB RAM, dual > quad core Xeon. I recompiled our kernel to use the ULE scheduler instead > of default. > > I could not get through an entire run of iozone without a system > reboot/crash. ZFS is clearly labeled experimental, of course. > > It seems to die for sure around 10 processes, sometimes less (this is > the end of my output from iozone): > > Children see throughput for 10 readers = 135931.72 KB/sec > Parent sees throughput for 10 readers = 135927.24 KB/sec > Min throughput per process = 13351.26 KB/sec > Max throughput per process = 14172.05 KB/sec > Avg throughput per process = 13593.17 KB/sec > Min xfer = 31586816.00 KB Can you tell us how does this compare to UFS2 results you posted previously? (since you used dd for UFS2 and now iozone for ZFS; what are your conclusions?) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080416/019054c2/signature.pgp From kris at FreeBSD.org Wed Apr 16 09:59:45 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Apr 16 09:59:48 2008 Subject: 10GbE speeds In-Reply-To: <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> Message-ID: <20080416095945.GA91566@hub.freebsd.org> On Wed, Apr 16, 2008 at 10:02:33AM +1000, Aristedes Maniatis wrote: > > On 15/04/2008, at 10:54 PM, gnn@freebsd.org wrote: > >I am working with the Chelsio hardware and it seems to be well > >supported on FreeBSD. All the machines in that system are FreeBSD > >though. How do you intend to get the OSX systems to be 10GE? > > > What sort of throughput are you getting with that setup? Are you using > NFS between the systems? I get about 150 MB/sec NFS random write throughput between chelsio NICs. We are still in the process of optimizing NFS at the high end. For bulk packet throughput it is not difficult to saturate it. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From Leonid.Grossman at neterion.com Wed Apr 16 15:17:56 2008 From: Leonid.Grossman at neterion.com (Leonid Grossman) Date: Wed Apr 16 15:32:16 2008 Subject: 10GbE speeds In-Reply-To: References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au><15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD770367B106@nekter> Neterion supports OS X on 10GbE NICs, I think Intel does as well (via third party). Leonid > -----Original Message----- > From: owner-freebsd-performance@freebsd.org [mailto:owner-freebsd- > performance@freebsd.org] On Behalf Of Kip Macy > Sent: Tuesday, April 15, 2008 5:09 PM > To: Aristedes Maniatis; gnn@freebsd.org; freebsd-performance@freebsd.org > Subject: Re: 10GbE speeds > > Myricom has OS X support, Chelsio has support in the works. I don't > know about Neterion or Intel. > > -Kip > > > > On 4/15/08, Aristedes Maniatis wrote: > > > > On 15/04/2008, at 10:54 PM, gnn@freebsd.org wrote: > > > I am working with the Chelsio hardware and it seems to be well > > > supported on FreeBSD. All the machines in that system are FreeBSD > > > though. How do you intend to get the OSX systems to be 10GE? > > > > > > What sort of throughput are you getting with that setup? Are you using > > NFS between the systems? > > > > Good question about OSX, and I hadn't got to that part yet :-) But I > > was hoping that some OSX drivers existed. My fail back plan is to put > > 3 x 1GbE NICs into the server and just use crossover cable between the > > 3 workstations and the server to avoid any contention within the > > ethernet network. > > > > Ari Maniatis > > > > > > --------------------------> > > ish > > http://www.ish.com.au > > Level 1, 30 Wilson Street Newtown 2042 Australia > > phone +61 2 9550 5001 fax +61 2 9550 4001 > > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > > > > _______________________________________________ > > freebsd-performance@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > > To unsubscribe, send any mail to > > "freebsd-performance-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance- > unsubscribe@freebsd.org" From bmeekhof at umich.edu Wed Apr 16 15:58:32 2008 From: bmeekhof at umich.edu (Benjeman Meekhof) Date: Wed Apr 16 15:58:42 2008 Subject: ZFS, Dell PE2950 In-Reply-To: References: <480548CF.5080104@umich.edu> Message-ID: <4806221C.20202@umich.edu> Sure, here is an example iozone output when I tested UFS2. Same hardware config as with ZFS test. #gstripe label -v -s 128k test /dev/mfid0 /dev/mfid2 #newfs -U -b 65536 /dev/stripe/test "Throughput report Y-axis is type of test X-axis is number of processes" "Record size = 512 Kbytes " "Output is in Kbytes/sec" " Initial write " 576953.38 613457.19 627091.58 626818.95 641763.54 626005.11 579073.92 553088.47 557498.71 556188.95 553340.92 548801.62 " Rewrite " 580755.31 621562.75 638209.55 573171.69 633114.27 616501.92 542520.70 541662.21 525603.64 529194.37 506230.25 490589.89 " Read " 505978.28 546837.12 565786.34 310994.23 309813.64 329930.91 351162.15 376940.64 408561.11 432157.69 452106.75 470176.39 " Re-read " 523917.72 581796.50 592393.28 314724.70 308485.12 327409.40 350913.96 381370.12 408105.25 434168.93 458742.49 475407.44 -Ben Ivan Voras wrote: > Benjeman J. Meekhof wrote: >> Hi, >> >> I posted earlier about some results with this same system using UFS2. >> Now trying to test ZFS. This is a Dell PE2950 with two Perc6 >> controllers and 4 md1000 disk shelves with 750GB drives. 16GB RAM, dual >> quad core Xeon. I recompiled our kernel to use the ULE scheduler instead >> of default. >> >> I could not get through an entire run of iozone without a system >> reboot/crash. ZFS is clearly labeled experimental, of course. >> >> It seems to die for sure around 10 processes, sometimes less (this is >> the end of my output from iozone): >> >> Children see throughput for 10 readers = 135931.72 KB/sec >> Parent sees throughput for 10 readers = 135927.24 KB/sec >> Min throughput per process = 13351.26 KB/sec >> Max throughput per process = 14172.05 KB/sec >> Avg throughput per process = 13593.17 KB/sec >> Min xfer = 31586816.00 KB > > Can you tell us how does this compare to UFS2 results you posted > previously? (since you used dd for UFS2 and now iozone for ZFS; what are > your conclusions?) > From ivoras at freebsd.org Wed Apr 16 20:21:16 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 16 20:21:24 2008 Subject: ZFS, Dell PE2950 In-Reply-To: <4806221C.20202@umich.edu> References: <480548CF.5080104@umich.edu> <4806221C.20202@umich.edu> Message-ID: Benjeman Meekhof wrote: > Sure, here is an example iozone output when I tested UFS2. Same > hardware config as with ZFS test. > > #gstripe label -v -s 128k test /dev/mfid0 /dev/mfid2 > #newfs -U -b 65536 /dev/stripe/test > > > "Throughput report Y-axis is type of test X-axis is number of processes" > "Record size = 512 Kbytes " > "Output is in Kbytes/sec" > > " Read " 505978.28 546837.12 565786.34 310994.23 > 309813.64 329930.91 351162.15 376940.64 408561.11 432157.69 > 452106.75 470176.39 > > " Re-read " 523917.72 581796.50 592393.28 314724.70 > 308485.12 327409.40 350913.96 381370.12 408105.25 434168.93 > 458742.49 475407.44 This is hard to compare to what you've posted before, but if it means that with ZFS you get 136 MB/s and with UFS 300-593 MB/s, something is wrong. Per my discussion with Scott Long Can you repeat the test for UFS, but create gstripe with a really small stripe size, like 4 KB? > -Ben > > Ivan Voras wrote: >> Benjeman J. Meekhof wrote: >>> Hi, >>> >>> I posted earlier about some results with this same system using UFS2. >>> Now trying to test ZFS. This is a Dell PE2950 with two Perc6 >>> controllers and 4 md1000 disk shelves with 750GB drives. 16GB RAM, dual >>> quad core Xeon. I recompiled our kernel to use the ULE scheduler instead >>> of default. >>> >>> I could not get through an entire run of iozone without a system >>> reboot/crash. ZFS is clearly labeled experimental, of course. >>> >>> It seems to die for sure around 10 processes, sometimes less (this is >>> the end of my output from iozone): >>> >>> Children see throughput for 10 readers = 135931.72 KB/sec >>> Parent sees throughput for 10 readers = 135927.24 >>> KB/sec >>> Min throughput per process = 13351.26 >>> KB/sec >>> Max throughput per process = 14172.05 >>> KB/sec >>> Avg throughput per process = 13593.17 >>> KB/sec >>> Min xfer = 31586816.00 KB >> >> Can you tell us how does this compare to UFS2 results you posted >> previously? (since you used dd for UFS2 and now iozone for ZFS; what are >> your conclusions?) >> > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080416/f928a8eb/signature.pgp From ivoras at freebsd.org Wed Apr 16 20:38:16 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 16 20:38:24 2008 Subject: ZFS, Dell PE2950 In-Reply-To: References: <480548CF.5080104@umich.edu> <4806221C.20202@umich.edu> Message-ID: Ivan Voras wrote: > Per my discussion with Scott Long Can you repeat the test for UFS, but > create gstripe with a really small stripe size, like 4 KB? Actually, no need to do that - it looks like iozone is doing quite random IO ops so it won't help you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080416/36e342e8/signature.pgp From bmeekhof at umich.edu Wed Apr 16 21:35:59 2008 From: bmeekhof at umich.edu (Benjeman J. Meekhof) Date: Wed Apr 16 21:36:06 2008 Subject: ZFS, Dell PE2950 In-Reply-To: References: <480548CF.5080104@umich.edu> <4806221C.20202@umich.edu> Message-ID: <4806713B.2060405@umich.edu> I have some old dd numbers from when I was experimenting to find a UFS/gstripe combination that wasn't horrifyingly slow to read. I was not then adjusting filesystem blocksize, and not until moving UFS2 bs to the maximum did initial results seem worth resuming iozone tests. Raid HW stripe-width is 128k. FWIW. # using 4k stripe, same as above #gstripe label -v -s 4k test /dev/mfid0 /dev/mfid2 #newfs -U /dev/stripe/test #time dd if=/dev/zero of=/test/deletafile bs=1M count=10240 #time dd if=/test/deletafile of=/dev/null bs=1M count=10240 #write: 26.5s 403665800 bps #read: 157s 68343843 bps -Ben Ivan Voras wrote: > Ivan Voras wrote: > >> Per my discussion with Scott Long Can you repeat the test for UFS, but >> create gstripe with a really small stripe size, like 4 KB? > > Actually, no need to do that - it looks like iozone is doing quite > random IO ops so it won't help you. > From mk at mkdev.eu Thu Apr 17 09:01:46 2008 From: mk at mkdev.eu (Markus Klaschka) Date: Thu Apr 17 09:01:59 2008 Subject: NFS performance In-Reply-To: <20080416095945.GA91566@hub.freebsd.org> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> <20080416095945.GA91566@hub.freebsd.org> Message-ID: <48070E93.9030705@mkdev.eu> That's interesting cause heavy reading from NFS brought me a loadavg of 70 and more if there were a lot of small files to read. I thought this is a normal issue about NFS... By the way, are all Realtek Cards for the bin or only the 8139...the server has a 'RTL8169 Gigabit Ethernet Adapter' I mean, you all know this, if not read the comments in that file ;) root@kalium:~ > grep worst /usr/src/sys/pci/if_rl.c * probably the worst PCI ethernet controller ever made, with the possible What could be configured wrong? What's the best way to test bandwidth if I only got one well connected server? pathchar? Cheers Markus Kris Kennaway schrieb: > On Wed, Apr 16, 2008 at 10:02:33AM +1000, Aristedes Maniatis wrote: > >> On 15/04/2008, at 10:54 PM, gnn@freebsd.org wrote: >> >>> I am working with the Chelsio hardware and it seems to be well >>> supported on FreeBSD. All the machines in that system are FreeBSD >>> though. How do you intend to get the OSX systems to be 10GE? >>> >> What sort of throughput are you getting with that setup? Are you using >> NFS between the systems? >> > > I get about 150 MB/sec NFS random write throughput between chelsio > NICs. We are still in the process of optimizing NFS at the high end. > For bulk packet throughput it is not difficult to saturate it. > > Kris > > -- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > -- Markus Klaschka MKDev - Markus Klaschka Development http://www.mkdev.eu Spain: 0034 - 63 747 23 07 UK: 0044 - 750 910 2718 Mail: mk@mkdev.eu Skype: mark-use IRC: mark-use @ irc.freenode.net : #freebsd, ##security, #freebsd-src, #bsdforen.de, #bsdgroup.de From kris at FreeBSD.org Thu Apr 17 12:31:42 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Apr 17 12:31:48 2008 Subject: NFS performance In-Reply-To: <48070E93.9030705@mkdev.eu> References: <5873E91C-C096-4EE1-A5F5-4BCE110E2EE7@ish.com.au> <15A6FBF6-052E-486D-9470-CAE5819BE93F@ish.com.au> <20080416095945.GA91566@hub.freebsd.org> <48070E93.9030705@mkdev.eu> Message-ID: <20080417123142.GI25623@hub.freebsd.org> On Thu, Apr 17, 2008 at 10:47:15AM +0200, Markus Klaschka wrote: > That's interesting cause heavy reading from NFS brought me a loadavg of > 70 and more if there were a lot of small files to read. > I thought this is a normal issue about NFS... > By the way, are all Realtek Cards for the bin or only the 8139...the > server has a 'RTL8169 Gigabit Ethernet Adapter' > I mean, you all know this, if not read the comments in that file ;) > > root@kalium:~ > grep worst /usr/src/sys/pci/if_rl.c > * probably the worst PCI ethernet controller ever made, with the > possible > > What could be configured wrong? > What's the best way to test bandwidth if I only got one well connected > server? pathchar? NFS performance is limited by several things: * server disk I/O. With low end disk hardware you are not going to get good performance at high load. * network bandwidth. Ditto. * NFS client and server implementation There have been important relevant improvements in 8.0 that improve the client performance with many concurrent processes doing NFS I/O. Also 7.0 has much better performance than 6.x. Kris P.S. Load average doesn't tell you if your system is performing badly, it tells you that the system is running many processes. -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From Andre.Albsmeier at siemens.com Tue Apr 22 11:29:31 2008 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Tue Apr 22 11:29:38 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <20080221121322.GO57756@deviant.kiev.zoral.com.ua> References: <20080214114759.R75215@mail.rsts.org> <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> Message-ID: <20080422103145.GA17645@curry.mchp.siemens.de> On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: > On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: > > > > On Wed, 20 Feb 2008, Kostik Belousov wrote: > > > > > I cannot reproduce it locally. With patch applied, it compiles both > > > GENERIC and GENERIC with options QUOTA added just fine. > > > > > > Check for partially applied patch. > > > > > > > Thanks Kostik. You can double check me on sizes, but it would appear that > > all files in the patch were touched, and I double checked my sources with: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are > The patch is against RELENG_6, not against RELENG_6_2. I see no point > in backporting it to RELENG_6_2. > > BTW, I backported two fixes, one for another deadlock with snapshots and > quotas, another for "ffs_blkfree: block already freed" panic and followed > up fsck: softdep inconsistency error. > > New combined patch (against RELENG_6) is at > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch I tried to apply this patch to recent RELENG_6 sources but it failed at a lot of places. I think this is due to changes to the tree after the above patch was made. Is there any newer patch available or is it possible to make one which applies to recent RELENG_6 sources? Thanks, -Andre -- "I think there is a world market for maybe five computers." - Thomas Watson, chairman of IBM, 1943 From kris at FreeBSD.org Tue Apr 22 12:08:30 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Apr 22 12:08:36 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <20080422115407.GP18958@deviant.kiev.zoral.com.ua> References: <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> <20080422115407.GP18958@deviant.kiev.zoral.com.ua> Message-ID: <480DD532.9000203@FreeBSD.org> Kostik Belousov wrote: > On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: >> On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: >>> On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: >>>> On Wed, 20 Feb 2008, Kostik Belousov wrote: >>>> >>>>> I cannot reproduce it locally. With patch applied, it compiles both >>>>> GENERIC and GENERIC with options QUOTA added just fine. >>>>> >>>>> Check for partially applied patch. >>>>> >>>> Thanks Kostik. You can double check me on sizes, but it would appear that >>>> all files in the patch were touched, and I double checked my sources with: >>>> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are >>> The patch is against RELENG_6, not against RELENG_6_2. I see no point >>> in backporting it to RELENG_6_2. >>> >>> BTW, I backported two fixes, one for another deadlock with snapshots and >>> quotas, another for "ffs_blkfree: block already freed" panic and followed >>> up fsck: softdep inconsistency error. >>> >>> New combined patch (against RELENG_6) is at >>> http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch >> I tried to apply this patch to recent RELENG_6 sources >> but it failed at a lot of places. I think this is due to >> changes to the tree after the above patch was made. >> >> Is there any newer patch available or is it possible to make >> one which applies to recent RELENG_6 sources? > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch > > May be, I shall commit it finally. FYI scottl@ was asking about this yesterday, and seemed interested in helping you to get it committed if necessary. Kris From kostikbel at gmail.com Tue Apr 22 12:11:54 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Apr 22 12:12:00 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <480DD532.9000203@FreeBSD.org> References: <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> <20080422115407.GP18958@deviant.kiev.zoral.com.ua> <480DD532.9000203@FreeBSD.org> Message-ID: <20080422121145.GQ18958@deviant.kiev.zoral.com.ua> On Tue, Apr 22, 2008 at 02:08:18PM +0200, Kris Kennaway wrote: > Kostik Belousov wrote: > >On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: > >>On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: > >>>On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: > >>>>On Wed, 20 Feb 2008, Kostik Belousov wrote: > >>>> > >>>>>I cannot reproduce it locally. With patch applied, it compiles both > >>>>>GENERIC and GENERIC with options QUOTA added just fine. > >>>>> > >>>>>Check for partially applied patch. > >>>>> > >>>>Thanks Kostik. You can double check me on sizes, but it would appear > >>>>that > >>>>all files in the patch were touched, and I double checked my sources > >>>>with: > >>>>ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which > >>>>are > >>>The patch is against RELENG_6, not against RELENG_6_2. I see no point > >>>in backporting it to RELENG_6_2. > >>> > >>>BTW, I backported two fixes, one for another deadlock with snapshots and > >>>quotas, another for "ffs_blkfree: block already freed" panic and followed > >>>up fsck: softdep inconsistency error. > >>> > >>>New combined patch (against RELENG_6) is at > >>>http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch > >>I tried to apply this patch to recent RELENG_6 sources > >>but it failed at a lot of places. I think this is due to > >>changes to the tree after the above patch was made. > >> > >>Is there any newer patch available or is it possible to make > >>one which applies to recent RELENG_6 sources? > > > >http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch > > > >May be, I shall commit it finally. > > FYI scottl@ was asking about this yesterday, and seemed interested in > helping you to get it committed if necessary. My worry is the possible mismerge. I do prefer to commit it now, after some authoritative "no problem seen" message. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080422/7cc79bcc/attachment.pgp From kostikbel at gmail.com Tue Apr 22 12:19:03 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Apr 22 12:19:09 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <20080422103145.GA17645@curry.mchp.siemens.de> References: <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> Message-ID: <20080422115407.GP18958@deviant.kiev.zoral.com.ua> On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: > On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: > > On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: > > > > > > On Wed, 20 Feb 2008, Kostik Belousov wrote: > > > > > > > I cannot reproduce it locally. With patch applied, it compiles both > > > > GENERIC and GENERIC with options QUOTA added just fine. > > > > > > > > Check for partially applied patch. > > > > > > > > > > Thanks Kostik. You can double check me on sizes, but it would appear that > > > all files in the patch were touched, and I double checked my sources with: > > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are > > The patch is against RELENG_6, not against RELENG_6_2. I see no point > > in backporting it to RELENG_6_2. > > > > BTW, I backported two fixes, one for another deadlock with snapshots and > > quotas, another for "ffs_blkfree: block already freed" panic and followed > > up fsck: softdep inconsistency error. > > > > New combined patch (against RELENG_6) is at > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch > > I tried to apply this patch to recent RELENG_6 sources > but it failed at a lot of places. I think this is due to > changes to the tree after the above patch was made. > > Is there any newer patch available or is it possible to make > one which applies to recent RELENG_6 sources? http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch May be, I shall commit it finally. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080422/f19fd9c0/attachment.pgp From kostikbel at gmail.com Tue Apr 22 13:36:02 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Apr 22 13:36:10 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <480D3D5F.3060704@samsco.org> References: <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> <20080422115407.GP18958@deviant.kiev.zoral.com.ua> <480DD532.9000203@FreeBSD.org> <20080422121145.GQ18958@deviant.kiev.zoral.com.ua> <480D3D5F.3060704@samsco.org> Message-ID: <20080422133525.GR18958@deviant.kiev.zoral.com.ua> On Mon, Apr 21, 2008 at 07:20:31PM -0600, Scott Long wrote: > Kostik Belousov wrote: > >On Tue, Apr 22, 2008 at 02:08:18PM +0200, Kris Kennaway wrote: > >>Kostik Belousov wrote: > >>>On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: > >>>>On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: > >>>>>On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: > >>>>>>On Wed, 20 Feb 2008, Kostik Belousov wrote: > >>>>>> > >>>>>>>I cannot reproduce it locally. With patch applied, it compiles both > >>>>>>>GENERIC and GENERIC with options QUOTA added just fine. > >>>>>>> > >>>>>>>Check for partially applied patch. > >>>>>>> > >>>>>>Thanks Kostik. You can double check me on sizes, but it would appear > >>>>>>that > >>>>>>all files in the patch were touched, and I double checked my sources > >>>>>>with: > >>>>>>ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which > >>>>>>are > >>>>>The patch is against RELENG_6, not against RELENG_6_2. I see no point > >>>>>in backporting it to RELENG_6_2. > >>>>> > >>>>>BTW, I backported two fixes, one for another deadlock with snapshots > >>>>>and > >>>>>quotas, another for "ffs_blkfree: block already freed" panic and > >>>>>followed > >>>>>up fsck: softdep inconsistency error. > >>>>> > >>>>>New combined patch (against RELENG_6) is at > >>>>>http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch > >>>>I tried to apply this patch to recent RELENG_6 sources > >>>>but it failed at a lot of places. I think this is due to > >>>>changes to the tree after the above patch was made. > >>>> > >>>>Is there any newer patch available or is it possible to make > >>>>one which applies to recent RELENG_6 sources? > >>>http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch > >>> > >>>May be, I shall commit it finally. > >>FYI scottl@ was asking about this yesterday, and seemed interested in > >>helping you to get it committed if necessary. > > > >My worry is the possible mismerge. I do prefer to commit it now, after > >some authoritative "no problem seen" message. > > I'll merge it into the FreeBSD 6 tree at Yahoo, get some testing done on > it, and then let you know how it goes. Thank you ! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080422/e275c329/attachment.pgp From scottl at samsco.org Tue Apr 22 13:38:40 2008 From: scottl at samsco.org (Scott Long) Date: Tue Apr 22 13:38:46 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <20080422121145.GQ18958@deviant.kiev.zoral.com.ua> References: <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> <20080422115407.GP18958@deviant.kiev.zoral.com.ua> <480DD532.9000203@FreeBSD.org> <20080422121145.GQ18958@deviant.kiev.zoral.com.ua> Message-ID: <480D3D5F.3060704@samsco.org> Kostik Belousov wrote: > On Tue, Apr 22, 2008 at 02:08:18PM +0200, Kris Kennaway wrote: >> Kostik Belousov wrote: >>> On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: >>>> On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: >>>>> On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: >>>>>> On Wed, 20 Feb 2008, Kostik Belousov wrote: >>>>>> >>>>>>> I cannot reproduce it locally. With patch applied, it compiles both >>>>>>> GENERIC and GENERIC with options QUOTA added just fine. >>>>>>> >>>>>>> Check for partially applied patch. >>>>>>> >>>>>> Thanks Kostik. You can double check me on sizes, but it would appear >>>>>> that >>>>>> all files in the patch were touched, and I double checked my sources >>>>>> with: >>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which >>>>>> are >>>>> The patch is against RELENG_6, not against RELENG_6_2. I see no point >>>>> in backporting it to RELENG_6_2. >>>>> >>>>> BTW, I backported two fixes, one for another deadlock with snapshots and >>>>> quotas, another for "ffs_blkfree: block already freed" panic and followed >>>>> up fsck: softdep inconsistency error. >>>>> >>>>> New combined patch (against RELENG_6) is at >>>>> http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch >>>> I tried to apply this patch to recent RELENG_6 sources >>>> but it failed at a lot of places. I think this is due to >>>> changes to the tree after the above patch was made. >>>> >>>> Is there any newer patch available or is it possible to make >>>> one which applies to recent RELENG_6 sources? >>> http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch >>> >>> May be, I shall commit it finally. >> FYI scottl@ was asking about this yesterday, and seemed interested in >> helping you to get it committed if necessary. > > My worry is the possible mismerge. I do prefer to commit it now, after > some authoritative "no problem seen" message. I'll merge it into the FreeBSD 6 tree at Yahoo, get some testing done on it, and then let you know how it goes. Scott From Andre.Albsmeier at siemens.com Tue Apr 22 17:39:29 2008 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Tue Apr 22 17:39:36 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <20080422115407.GP18958@deviant.kiev.zoral.com.ua> References: <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> <20080422115407.GP18958@deviant.kiev.zoral.com.ua> Message-ID: <20080422163430.GA20691@curry.mchp.siemens.de> On Tue, 22-Apr-2008 at 14:54:07 +0300, Kostik Belousov wrote: > On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: > > On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: > > > On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: > > > > > > > > On Wed, 20 Feb 2008, Kostik Belousov wrote: > > > > > > > > > I cannot reproduce it locally. With patch applied, it compiles both > > > > > GENERIC and GENERIC with options QUOTA added just fine. > > > > > > > > > > Check for partially applied patch. > > > > > > > > > > > > > Thanks Kostik. You can double check me on sizes, but it would appear that > > > > all files in the patch were touched, and I double checked my sources with: > > > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are > > > The patch is against RELENG_6, not against RELENG_6_2. I see no point > > > in backporting it to RELENG_6_2. > > > > > > BTW, I backported two fixes, one for another deadlock with snapshots and > > > quotas, another for "ffs_blkfree: block already freed" panic and followed > > > up fsck: softdep inconsistency error. > > > > > > New combined patch (against RELENG_6) is at > > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch > > > > I tried to apply this patch to recent RELENG_6 sources > > but it failed at a lot of places. I think this is due to > > changes to the tree after the above patch was made. > > > > Is there any newer patch available or is it possible to make > > one which applies to recent RELENG_6 sources? > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch That was a quick one, thanks a lot! -Andre > > May be, I shall commit it finally. -- GNU is Not Unix / Linux Is Not UniX From freebsd at sopwith.solgatos.com Thu Apr 24 18:37:13 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Apr 24 18:37:17 2008 Subject: vfs.write_behind Message-ID: <200804241800.SAA11746@sopwith.solgatos.com> The handbook says: The vfs.write_behind sysctl variable defaults to 1 (on). This tells the file system to issue media writes as full clusters are collected, which typically occurs when writing large sequential files. The idea is to avoid saturating the buffer cache with dirty buffers when it would not benefit I/O performance. However, this may stall processes and under certain circumstances you may wish to turn it off. Looking through the documentation, I can't find an explaination of what a cluster is. Multiple blocks? How would this stall processes? Seems backwards. If you don't have write-behind, a process would block until the data gets written to the media. So if vfs.write_behind is 0, then a larger number of smaller writes are issued? From Andre.Albsmeier at siemens.com Fri Apr 25 13:56:11 2008 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Fri Apr 25 13:56:16 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <20080422163430.GA20691@curry.mchp.siemens.de> References: <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> <20080422115407.GP18958@deviant.kiev.zoral.com.ua> <20080422163430.GA20691@curry.mchp.siemens.de> Message-ID: <20080425135602.GA1293@curry.mchp.siemens.de> On Tue, 22-Apr-2008 at 18:34:30 +0200, Andre Albsmeier wrote: > On Tue, 22-Apr-2008 at 14:54:07 +0300, Kostik Belousov wrote: > > On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: > > > On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: > > > > On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: > > > > > > > > > > On Wed, 20 Feb 2008, Kostik Belousov wrote: > > > > > > > > > > > I cannot reproduce it locally. With patch applied, it compiles both > > > > > > GENERIC and GENERIC with options QUOTA added just fine. > > > > > > > > > > > > Check for partially applied patch. > > > > > > > > > > > > > > > > Thanks Kostik. You can double check me on sizes, but it would appear that > > > > > all files in the patch were touched, and I double checked my sources with: > > > > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are > > > > The patch is against RELENG_6, not against RELENG_6_2. I see no point > > > > in backporting it to RELENG_6_2. > > > > > > > > BTW, I backported two fixes, one for another deadlock with snapshots and > > > > quotas, another for "ffs_blkfree: block already freed" panic and followed > > > > up fsck: softdep inconsistency error. > > > > > > > > New combined patch (against RELENG_6) is at > > > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch > > > > > > I tried to apply this patch to recent RELENG_6 sources > > > but it failed at a lot of places. I think this is due to > > > changes to the tree after the above patch was made. > > > > > > Is there any newer patch available or is it possible to make > > > one which applies to recent RELENG_6 sources? > > > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch > I have this patch now running on a CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3001.18-MHz 686-class CPU) machine. I have attached two 10k SCSI drives to an AIC7902 controller. These two drives have quotas enabled and are constantly copying 77GB of data stored in ~210000 files to each other. I use about 75 different user and group IDs with these files. I haven't had any problem the last 6 hours. The machine runs rocksolid and the quota values are correct. So, from my point of view I'd say that the patch works great! Thanks a lot for the nice work, -Andre From kostikbel at gmail.com Fri Apr 25 14:07:05 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Apr 25 14:07:08 2008 Subject: System perforamance 4.x vs. 5.x and 6.x In-Reply-To: <20080425135602.GA1293@curry.mchp.siemens.de> References: <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> <20080221121322.GO57756@deviant.kiev.zoral.com.ua> <20080422103145.GA17645@curry.mchp.siemens.de> <20080422115407.GP18958@deviant.kiev.zoral.com.ua> <20080422163430.GA20691@curry.mchp.siemens.de> <20080425135602.GA1293@curry.mchp.siemens.de> Message-ID: <20080425140657.GE18958@deviant.kiev.zoral.com.ua> On Fri, Apr 25, 2008 at 03:56:02PM +0200, Andre Albsmeier wrote: > On Tue, 22-Apr-2008 at 18:34:30 +0200, Andre Albsmeier wrote: > > On Tue, 22-Apr-2008 at 14:54:07 +0300, Kostik Belousov wrote: > > > On Tue, Apr 22, 2008 at 12:31:45PM +0200, Andre Albsmeier wrote: > > > > On Thu, 21-Feb-2008 at 14:13:22 +0200, Kostik Belousov wrote: > > > > > On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: > > > > > > > > > > > > On Wed, 20 Feb 2008, Kostik Belousov wrote: > > > > > > > > > > > > > I cannot reproduce it locally. With patch applied, it compiles both > > > > > > > GENERIC and GENERIC with options QUOTA added just fine. > > > > > > > > > > > > > > Check for partially applied patch. > > > > > > > > > > > > > > > > > > > Thanks Kostik. You can double check me on sizes, but it would appear that > > > > > > all files in the patch were touched, and I double checked my sources with: > > > > > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are > > > > > The patch is against RELENG_6, not against RELENG_6_2. I see no point > > > > > in backporting it to RELENG_6_2. > > > > > > > > > > BTW, I backported two fixes, one for another deadlock with snapshots and > > > > > quotas, another for "ffs_blkfree: block already freed" panic and followed > > > > > up fsck: softdep inconsistency error. > > > > > > > > > > New combined patch (against RELENG_6) is at > > > > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.patch > > > > > > > > I tried to apply this patch to recent RELENG_6 sources > > > > but it failed at a lot of places. I think this is due to > > > > changes to the tree after the above patch was made. > > > > > > > > Is there any newer patch available or is it possible to make > > > > one which applies to recent RELENG_6 sources? > > > > > > http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080422-1000.patch > > > > I have this patch now running on a > > CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3001.18-MHz 686-class CPU) > > machine. I have attached two 10k SCSI drives to an AIC7902 > controller. These two drives have quotas enabled and are > constantly copying 77GB of data stored in ~210000 files to > each other. I use about 75 different user and group IDs with > these files. > > I haven't had any problem the last 6 hours. The machine runs > rocksolid and the quota values are correct. So, from my point > of view I'd say that the patch works great! > > Thanks a lot for the nice work, > Andre, thank you for the report. There is one more testing performed by Scott Long. After his confirmation I will commit it, finally. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20080425/cb05be92/attachment.pgp