Re: Performance!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Here are lock profiling results with select patch applied. OK, you are doing I/O over TCP. Are you sure you are using TCP on both systems? Linux may not be defaulting to TCP transport for local queries. Add --pgsql-host= to your sysbench command line to make it communicate over a local domain socket, which is much more efficient. Kris Hmm, Yes linux uses local domain sockets! Here are results using local domain sockets on FreeBSD too: #threads#tranzactions/sec 1 728 5 2996 10 5301 20 3931 40 2466 60 1852 80 1424 100 1216 Just to remember: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 I have results using Fedora 8 on the same hardware: Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 If we look at the results with up to 10 threads the performance of FreeBSD is very good. May be something can be tuned for number of threads number of CPUs? Are you interested in lock profiling statistics with more threads than the number of CPUs? Yes, it's still performing anomalously. Glad we're making progress though :) Kris Okay, but how many threads will be more useful to test with? Let's start with 8 and say 40. The two problems seem to be slightly lower peak and poor scaling above peak. They might be the same, or they might be different. kris I sent to you the results with 8 and 40 threads. The lower peak may be caused by differences in installations like different partitions I use ... The most important is keeping performance above this peak. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHh06CxJBWvpalMpkRAjosAJ0djbiU/foRiI+/ne1YyuqnVjKOaACfRCpV fI3vb0m1I+fIZ1M7cHCBjR8= =jiPg -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
Anish Mistry wrote: On Friday 04 January 2008, Kris Kennaway wrote: Kris Kennaway wrote: David E. Thiel wrote: On Sun, Dec 30, 2007 at 11:12:26PM +0100, Kris Kennaway wrote: FWIW, the problem remains for me. Still terrible performance during compiles. OK. Instead of going over all of the usual questions again, can you point me to a previous mail in which you explain your observations and test results in detail? The most recent is http://marc.info/?l=freebsd-stablem=119428719505129w=2, but it started way back at http://marc.info/?l=freebsd-currentm=118998090512027w=2. I've tried a lot of stuff in between, and all I've been able to narrow it down to is that it's not a display driver issue, and that none of my swap partition is getting used, so that's not the problem. During compiles, my UP system with ULE still gets very unresponsive when compiling, sometimes taking up to 10 seconds just to draw a new terminal window. Even changing focus with the window manager can take several seconds. I'd like to provide more info, but I'm not sure what stats are useful for this particular issue. Please let me know. dmesg is at http://redundancy.redundancy.org/dmesg.txt, and kernel config is at http://redundancy.redundancy.org/DEEPTHOUGHT. Even though I'm still getting reported 80-95% memory utilization and no paging, I'm going to get an extra gig of RAM on order to see if that improves things. 2G of ram for a desktop, what's the world coming to? ;) OK, can you obtain a schedgraph trace when the problem is manifesting? See /usr/src/tools/sched/ and previous discussion in this or related threads. Anyone? Time is rapidly running out to get this fixed in time for 7.0-RELEASE, so we need this trace ASAP. http://am-productions.biz/docs/ktr.out.gz Is there a way to export the graph once I'm looking in it in schedgraph.py? The above trace does not show any compiler activity. What was the process that was interfering with X performance in your case? You also have a CPU load of up to 17, which is rather high. I am not sure it is reasonable to expect your machine to stay perfectly responsive while it is under that kind of load. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sticky sound on 7 stable
Hi stable@ I have sticky sound flow on 2 different slowish laptops running 7 Stable, Sound plays for a few secs, then breaks for a fraction resumes, repeatedly. I guess fault is not sound config, hence I'm not posting multimedia@, but stable@ where I've seen other Sticky 7 response topics. I have 3 test files: -rwxr-xr-x 1 jhs staff 32521108 Dec 9 18:01 1.avi* -rw-r- 1 jhs staff 3859434 Dec 6 11:03 audio_01.mp3 -rw-r- 1 jhs staff 42535964 Dec 6 11:02 audio_01.wav 1.avi:RIFF (little-endian) data, AVI, 320 x 240, ~15 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 11024 Hz) audio_01.mp3: MPEG ADTS, layer III, v1, 128 kBits, 44.1 kHz, JntStereo audio_01.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz 1.avi is from my digital camera: a short movie. (nothing wrong with 1.avi on a faster laptop running 6.2-REL) mplayer plays it in bursts. screen is local, no ethernet activity, no other disc acrivity (makes etc) Only other processe I have are idle sshd apache such, nothing active. No disc activity until I start the music player. on a dir of / thus no soft updates also on a dir of /usr with soft updates mplayer *.wav (plays fine on a faster 6.2 box) Plays normal speed on the slower CPU (where top shows 6 to 0% free). but occasional interruptions. ie sticky. (no pcmcia ethernet activity, I can control it via SLIP!) Plays slow on the faster CPU! (where top shows 10% free CPU) (unusual machine, 5 pcmcia slots, maybe irqs or other conf. screwed, thus pcmcia ethernet works.) Also interruptions. ksmp3play audio_01.mp3 (plays fine on a faster 6.2 box) Really bad break up, this could be a different simpler problem ? Maybe my CPU can't decompress fast enough ? Maybe this not a FreeBSD problem ? I think I tried swapoff on all partitions, then building a little ram disc for the mp3, no improvement. Much other info on both laptops their BSD conf. here: host=lapd CPU 166M 586 http://www.berklix.com/~jhs/hardware/digital/ host=lapn CPU 133M 586 http://www.berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st/ Many dmesg other debug info linked within, anything else you want please just tell me debug command to run. I'm happy to try src/ sys/ patches etc. Pref. based on 7-stable. Both have /boot/loader.conf: hw.ata.ata_dma=0 # Essential else disk access fails. Could that be it ? both report from xs atacontrol mode ad0 current mode = PIO4 I dont know about HZ setting, or different schedulers, but happy to try sysctls or tweak kernel configs if people suggest ideas ? Should I be using rtprio or that SCHED/ULE whatever swapper ? At least the same model Digital laptop has played sound for others on older FreeBSD. Ideas, comments, TYFM URLs all welcome, Thanks ! Julian -- Julian Stacey. Munich Consultant: BSD Linux Unix. http://berklix.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vinvalbuf: dirty bufs
Attached is the stack...
I was trying to back up a DVD (acd0) to a file-system (on ad8). According to
the ``systat 1 -vm'' window frozen on my screen, the system was processing an
awful lot of interrupts, when it paniced.
I have the entire vmcore. Attached is the debugger's stack of it. The kernel
is 6.3-PRERELEASE as of Dec 30th.
Please, advise. Thanks,
-mi
Unread portion of the kernel message buffer:
panic: vinvalbuf: dirty bufs
cpuid = 0
Uptime: 7d3h6m7s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 (CTRL-C to abort) (CTRL-C to abort)
(CTRL-C to abort) 687 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort)
671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367
351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31
15
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802b9a47 in boot (howto=260)
at /var/src/sys/kern/kern_shutdown.c:409
#3 0x802ba0e1 in panic (fmt=0xff00597f54c0 )
at /var/src/sys/kern/kern_shutdown.c:565
#4 0x80324a3f in bufobj_invalbuf (bo=0xff0016f58910, flags=1,
td=0xff00597f54c0, slpflag=0, slptimeo=0)
at /var/src/sys/kern/vfs_subr.c:1032
#5 0x80327657 in vgonel (vp=0xff0016f587c0)
at /var/src/sys/kern/vfs_subr.c:2453
#6 0x803286ae in vgone (vp=0xff0016f587c0)
at /var/src/sys/kern/vfs_subr.c:2408
#7 0x80267fad in devfs_delete (dm=0xff0005bf2900,
de=0xff0012557d00, vp_locked=0)
at /var/src/sys/fs/devfs/devfs_devs.c:265
#8 0x80268576 in devfs_populate_loop (dm=0xff0005bf2900,
cleanup=0) at /var/src/sys/fs/devfs/devfs_devs.c:384
#9 0x802685d9 in devfs_populate (dm=0xff0005bf2900)
at /var/src/sys/fs/devfs/devfs_devs.c:486
#10 0x8026ace4 in devfs_lookup (ap=0x0)
at /var/src/sys/fs/devfs/devfs_vnops.c:587
#11 0x8046838d in VOP_LOOKUP_APV (vop=0x805e6900,
a=0xd52f68a0) at vnode_if.c:99
#12 0x8031d9b5 in lookup (ndp=0xd52f6a20) at vnode_if.h:56
#13 0x8031e6e5 in namei (ndp=0xd52f6a20)
at /var/src/sys/kern/vfs_lookup.c:216
#14 0x8032fe04 in kern_stat (td=0xff00597f54c0, path=0x0,
pathseg=UIO_USERSPACE, sbp=0xd52f6af0)
at /var/src/sys/kern/vfs_syscalls.c:2077
#15 0x8032ff87 in stat (td=0x0, uap=0xd52f6bc0)
at /var/src/sys/kern/vfs_syscalls.c:2061
#16 0x8041e431 in syscall (frame=
{tf_rdi = 4620026, tf_rsi = 140737488350224, tf_rdx = 1200063540, tf_rcx
= 34378002812, tf_r8 = -2141280448, tf_r9 = 140737488350168, tf_rax = 188,
tf_rbx = 0, tf_rbp = 5763328, tf_r10 = -1098187407360, tf_r11 = 582, tf_r12 =
140737488350224, tf_r13 = 1200063360, tf_r14 = 0, tf_r15 = 0, tf_trapno = 22,
tf_addr = 0, tf_flags = 140737488247792, tf_err = 2, tf_rip = 34378002748,
tf_cs = 43, tf_rflags = 582, tf_rsp = 140737488350200, tf_ss = 35})
at /var/src/sys/amd64/amd64/trap.c:807
#17 0x80403938 in Xfast_syscall ()
at /var/src/sys/amd64/amd64/exception.S:287
#18 0x00080116b13c in ?? ()
(kgdb) ___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD tar errors on valid empty tar.gz
- Original Message - From: Kris Kennaway [EMAIL PROTECTED] Not that I'm aware of. gtar works but libarchive tar fails on the file it created. Yes, in 6.2. What about the report that it works in 6.3? Sorry didn't see that, out of order emails coming through no doubt :) Glad to hear its fixed in 6.3 / 7 Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sticky sound on 7 stable
On Fri, Jan 11, 2008 at 03:44:36PM +0100, Julian Stacey wrote: Hi stable@ I have sticky sound flow on 2 different slowish laptops running 7 Stable, Sound plays for a few secs, then breaks for a fraction resumes, repeatedly. I guess fault is not sound config, hence I'm not posting multimedia@, but stable@ where I've seen other Sticky 7 response topics. Much other info on both laptops their BSD conf. here: host=lapd CPU 166M 586 http://www.berklix.com/~jhs/hardware/digital/ host=lapn CPU 133M 586 http://www.berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st/ Many dmesg other debug info linked within, anything else you want please just tell me debug command to run. I'm happy to try src/ sys/ patches etc. Pref. based on 7-stable. Both have /boot/loader.conf: hw.ata.ata_dma=0 # Essential else disk access fails. Could that be it ? both report from xs atacontrol mode ad0 current mode = PIO4 This won't help. Mayby there is a BIOS setting that would enable you to run with dma enabled. I dont know about HZ setting, or different schedulers, but happy On 7.x, it is recommended to use SCHED_ULE. I'm not sure what compiling the kernel with HZ=1000 would accomplish, the default is HZ=100. See Have a look at the sound(4) manual page. There are some sysctls that influence latency; hw.snd.latency_profile and hw.snd.latency. If the problem is IRQ processing, you could try setting dev.pcm.0.polling to 1 if the driver supports it. Another thing to check is if the sound card isn't sharing an interrupt with other devices. The command 'ps -xa | grep irq' would be of use there. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpQ4krOeTJ0D.pgp Description: PGP signature
Re: RELENG_7 2008/01/10 desktop system also periodically freezes
On Thu, 10 Jan 2008 08:32:12 +0100, Kris Kennaway [EMAIL PROTECTED] wrote: J.R. Oldroyd wrote: On Wed, 09 Jan 2008 20:38:29 +0100, Kris Kennaway [EMAIL PROTECTED] wrote: OK, same requests as to the others then. I presume you mean hwpmc... LOCK_PROFILING, sched_graph, hwpmc. Quick update on this so that folk know what's going on. Firstly, I've updated the code here to RELENG_7 csup'd yesterday and if I run a normal kernel, without debugging, I do see the same freezes with that, too. Secondly, I am unable to process hwpcm dumps using pmcstat because it core dumps when using the -R option to decode a dump. I will talk to jkoshy@ about that. I am now running a kernel with LOCK_PROFILING. I am able to create a freeze due to the softupdate activity by removing a large file; a lock profile captured surrounding such a freeze can be seen here: http://opal.com/jr/freebsd/releng_7-freeze/20080135-softupdate.txt This is easily repeatable. The sequence is: create 1.5GB file sysctl debug.lock.prof.enable=1 rm file ... wait, moving mouse until it freezes then unfreezes ... sysctl debug.lock.prof.enable=0 sysctl debug.lock.prof.stats Kostik, is this of any help to you? I have yet to experience a random freeze not directly attributable to a softupdate while running the lock profiling. I am running with lock profiling on, and resetting the profiling counters once a minute. Yesterday and this morning, I've run for quite a while now with lock profiling on but without a random freeze. I'll wait some more, but I'm hoping that enabling the lock profiling hasn't masked the freeze. I'll post again when I see one.. -jr signature.asc Description: PGP signature
Re: Swapping caused by very large (regular) file size
Ian West wrote: Hello, I have noticed while benchmarking a system with a fair bit of ram (3G usable of 4G installed) that when using a very large file (3G upwards) in a simple benchmark it will cause the system to swap, even though the actual process does not show in top to be using a lot of memory, as soon as the swapping starts the throughput degrades dramatically. The 'inactive' ram shown in top increases rapidly and 'free' ram reduces, this seems fair and sensible, but allowing it to then page to possibly the same spindle/array seems like a bad idea ? I have tested this on a 4.11 system with 512M of ram as well as a RELENG-6 system with an areca raid controller, both behave in the same way, once the file gets to a certain size the system starts paging. Is there any way to tune this behaviour ? The test I have been doing is just generating a big file full of nulls, but bonnie++ causes the same behaviour with very large file sizes. dd if=/dev/zero bs=32768 of=junkfile count=10 seems to do it quite reliably on all the boxes I have tested ? Using cp to copy the file doesnt appear to cause the problem. Any thoughts or suggestions would be much appreciated ? I am unable to reproduce this on 7.0. On a system with 4GB of RAM, creating an 8GB file causes almost all of memory to be allocated to 'inactive' (as expected; these are cached pages in case something accesses the file again). However when free memory gets down to about 110M the inactive pages are replaced and free memory does not drop below this. Can you confirm whether 7.0 continues to manifest the problem for you? kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
Krassimir Slavchev wrote: I have read all related threads about performance problems with multi core systems but still have no idea what to do to make thinks better. Below are results of testing postgresql on HP DL380G5 using sysbench. The results are comparable to: http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 but the same tests running on the same hardware using Linux (kernel 2.6.18-53.1.4.el5 SMP x86_64) are very different. PostgreSQL is tuned equal. Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threadstransactions/sec 1 755 8 7129 40 6580 100 6768 compared to Linux: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 I think this is a satisfactory resolution :) Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
I have read all related threads about performance problems with multi core systems but still have no idea what to do to make thinks better. Below are results of testing postgresql on HP DL380G5 using sysbench. The results are comparable to: http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 but the same tests running on the same hardware using Linux (kernel 2.6.18-53.1.4.el5 SMP x86_64) are very different. PostgreSQL is tuned equal. Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threadstransactions/sec 1 755 8 7129 40 6580 100 6768 compared to Linux: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 I think this is a satisfactory resolution :) Thank you so much! (both of you and those who helped along the way) :-) On monday I will start testing a setup where we are moving from four 10K rpm sas disk in raid 1+0 to eight 15K rpm sas disks in raid 1+0 as well. The former is a ciss p400 controller with 512 MB bbc and the latter is a p800 with 512 MB bbc and an external msa-box. I will test with 7.0 and postgresql 8.2 from ports. Should I test with stable or release? Are there any patches I can apply? Our current db-server is a DL380 G5 woodcrest at 3 Ghz and my test-server will be a 8-core DL360 G5 at 2.4 Ghz (I think). I will log the queries from our live-server and repeat them on the test-server, use pgbench on FreeBSD, Solaris and Linux. I was getting a bit worried when the number varied so much between Linux and FreeBSD. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
On Fri, 11 Jan 2008 18:15:08 +0100 Kris Kennaway [EMAIL PROTECTED] wrote: Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threads transactions/sec 1 755 8 7129 406580 100 6768 compared to Linux: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 I think this is a satisfactory resolution :) That's great news! Even greater if you consider that not a single line of code inside FreeBSD had to be changed. -- Ricardo Nabinger Sanchez [EMAIL PROTECTED] Powered by FreeBSD http://rnsanchez.wait4.org Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
At 12:15 PM 1/11/2008, Kris Kennaway wrote: Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Thats great news! Just for the record, for build options are there any other options that need to be set other than # diff -u Makefile.default Makefile --- Makefile.default2008-01-11 20:13:06.0 -0500 +++ Makefile2008-01-11 20:16:02.0 -0500 @@ -87,7 +87,7 @@ OPTIONS+= HEIMDAL_KRB5 Builds with Heimdal kerberos support off OPTIONS+= OPTIMIZED_CFLAGS Builds with compiler optimizations (-O3) off OPTIONS+= LIBC_R Link w/ libc_r, used by plpython (server) off -OPTIONS+= THREADSAFE make libpq thread safe off +OPTIONS+= THREADSAFE make libpq thread safe on # to run regression tests: OPTIONS+= TESTS Allows the use of a \check\ target (server) off OPTIONS+= DEBUG Builds with debugging symbols off ? In terms of the kernel was this with ULE or SCHED_4BSD ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
Mike Tancsa wrote: At 12:15 PM 1/11/2008, Kris Kennaway wrote: Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Thats great news! Just for the record, for build options are there any other options that need to be set other than # diff -u Makefile.default Makefile --- Makefile.default2008-01-11 20:13:06.0 -0500 +++ Makefile2008-01-11 20:16:02.0 -0500 @@ -87,7 +87,7 @@ OPTIONS+= HEIMDAL_KRB5 Builds with Heimdal kerberos support off OPTIONS+= OPTIMIZED_CFLAGS Builds with compiler optimizations (-O3) off OPTIONS+= LIBC_R Link w/ libc_r, used by plpython (server) off -OPTIONS+= THREADSAFE make libpq thread safe off +OPTIONS+= THREADSAFE make libpq thread safe on # to run regression tests: OPTIONS+= TESTS Allows the use of a \check\ target (server) off OPTIONS+= DEBUG Builds with debugging symbols off That is necessary for the sysbench client, which is threaded. I don't know if there are any implications for non-threaded applications, but I would hope not. This was with the ULE scheduler, which is basically mandatory for good performance on SMP systems. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapping caused by very large (regular) file size
On Fri, Jan 11, 2008 at 06:44:20PM +0100, Kris Kennaway wrote: Ian West wrote: dd if=/dev/zero bs=32768 of=junkfile count=10 seems to do it quite reliably on all the boxes I have tested ? I am unable to reproduce this on 7.0. I can't reproduce it on 6.3-PRERELEASE/amd64 with 1GB RAM. vmstat -s;dd if=/dev/zero bs=32768 of=junkfile count=10;vmstat -s shows the following changes: 2 swap pager pageins 2 swap pager pages paged in 4 swap pager pageouts 5 swap pager pages paged out 24 vnode pager pageins 78 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out -- 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. pgphFm24TLtfp.pgp Description: PGP signature
Re: Swapping caused by very large (regular) file size
On Friday 11 January 2008 10:31:47 pm Peter Jeremy wrote: On Fri, Jan 11, 2008 at 06:44:20PM +0100, Kris Kennaway wrote: Ian West wrote: dd if=/dev/zero bs=32768 of=junkfile count=10 seems to do it quite reliably on all the boxes I have tested ? I am unable to reproduce this on 7.0. I can't reproduce it on 6.3-PRERELEASE/amd64 with 1GB RAM. vmstat -s;dd if=/dev/zero bs=32768 of=junkfile count=10;vmstat -s shows the following changes: 2 swap pager pageins 2 swap pager pages paged in 4 swap pager pageouts 5 swap pager pages paged out 24 vnode pager pageins 78 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out You may not have a fast enough disk. We have noticed an issue at work but only on faster controllers (e.g. certain mfi(4) drive configurations) when doing I/O to a single file like the dd command mentioned causes the buffer cache to fill up. The problem being that we can't lock the vm object to recycle pages when we hit the limit that is supposed to prevent this because all the pages in the cache are for the file (vm object) we are working on. Stephan (ups@) says this is fixed in 7. The tell-tale sign that we see is pagedaemon starts chewing up lots of CPU as the kernel tries to realign the page queues along with I/O throughput going down the toilet and being very erratic. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
