Re: Some performance testing?
От | Graeme B. Bell |
---|---|
Тема | Re: Some performance testing? |
Дата | |
Msg-id | 6745290C-E1DC-4A2E-B461-31EA53C76E38@skogoglandskap.no обсуждение исходный текст |
Ответ на | Re: Some performance testing? (Scott Marlowe <scott.marlowe@gmail.com>) |
Список | pgsql-performance |
The 3.10 mainline had a bug which crashes on boot for us, I think it was the network card driver for the R620. Can't recall. The equipment is in continual use so unfortunately we can't test other kernels at the moment but hopefully someone else maybe interested. It's probably valuable to compare against 3.19 too for anyone who doesn't want to delve into kernel archeology. Kernel performance gains will be sensitive to things like VM settings, scheduler settings, NUMA, hardware choice, BIOS settingsetc, use of virtualisation, so it depends which codepaths you end up running. So it may not be meaningful to comparekernels without a range of system configurations to measure against. ie. Your mileage will probably vary dependingon how far you've tuned your disk configuration, memory, etc. Graeme Bell On 09 Apr 2015, at 17:15, Scott Marlowe <scott.marlowe@gmail.com> wrote: > On Thu, Apr 9, 2015 at 7:35 AM, Graeme B. Bell <grb@skogoglandskap.no> wrote: >> ext4 settings >> >> ext4, nobarrier >> noatime+nodatime, >> stripe&stride aligned between raid10 & ext4 correctly. >> >> >> Some other useful things to know >> >> -- h710p >> readahead disabled on H710P >> writeback cache enabled on H710P >> Direct IO enabled on H710P >> >> -- os filesystem settings >> linux readahead enabled (16384), >> nr_requests=975 >> NOOP scheduler >> non-NUMA >> >> -- pg >> io_concurrency on >> async commit.*** see below! >> >> All settings were kept identical on the server before and after the kernel change, so this performance increase can beentirely attributed to the newer kernel and its synergies with our configuration. 3.18 contains about 5-10 years of linuxkernel development vs. 2.6 kernels (except where backported). >> >> I have conducted quite a lot of plug-pull testing with diskchecker.pl, and rather a lot of testing of scheduling/IO/RAIDcontroller/etc parameters. The OS/RAID controller/file system settings are as fast as I've been able toachieve without compromising database integrity (please note: this server can run async_commit because of the work weuse it for, but we do not use that setting on our other main production servers). >> >> Our local DBs run extremely nicely for all our normal queries which involve quite a mix of random small IO and full-tableoperations on e.g. 20GB+ tables , so they're not optimised for pgbench specifically. > > It would be handy to see a chart comparing 3.11, 3.13 and 3.18 as > well, to see if most / any of those performance gains came in earlier > kernels, but after 2.6 or 3.2 etc. > > Can confirm that for pg purposes, 3.2 is basically broken in some not > to great ways. We've had servers that were overloaded at load factors > of 20 or 30 drop down to 5 or less with just a change from 3.2 to > 3.11/3.13 on ubuntu 12.04
В списке pgsql-performance по дате отправления: