Re: ext3 filesystem / linux 7.3
От | Andrew Sullivan |
---|---|
Тема | Re: ext3 filesystem / linux 7.3 |
Дата | |
Msg-id | 20030403025816.GA17411@libertyrms.info обсуждение исходный текст |
Ответ на | Re: ext3 filesystem / linux 7.3 (Chris Hedemark <chrish@trilug.org>) |
Список | pgsql-performance |
On Wed, Apr 02, 2003 at 09:44:31PM -0500, Chris Hedemark wrote: > While the server is admittedly an older machine, for the purpose of > this test it should not matter as long as the hardware configuration is > equal for all tests. If we agree on a test suite there is nothing to That's false. One of the big problems with a lot of tuning info is that it tends not to take int consideration hardware, &c. I can tell you for sure that if you have a giant-cache array connected by fibre channel, _it makes no difference_ what the filesystem is. The array is so fast that you can't really fill the cache under normal load anyway. Similarly, if you have enough memory, every read test is going to be as fast as any other: you'll get 100% cache hits, and the same memory configured the same way will always respond at about the same speed. That said, I think you're right to demand some tests, and to say that holding the machine constant and changing filesystems is a good filesystem test. So here are some suggested things, in no real order: 1. Make sure you run out of buffers before you start to read (for read filesystem speed tests). 2. Pull the power plug repeatedly while the server is under load. Judge robustness. 3. Put WAL and data area on different filesystems (to be fair, this should probably be different spindles, but I'll take what I can get) and configure the filesystems in various ways (including, say, writeback for data and full journalling for WAL). See tests above. 4. Make sure your controller doesn't lie about fsync. 5. Test under different loads. 10% writes vs. 90% reads; 20% writes; &c. Compare simple INSERT write with UPDATE write. Compare UPDATE writes where the UPDATEd row is the same one over and over. Make sure you do (2) several times. Lots of these are artificial. But it seems they might reveal something. I'd be particularly keen to hear about what _really_ is up with reiserfs. A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
В списке pgsql-performance по дате отправления: