Re: Block at a time ...
От | Pierre C |
---|---|
Тема | Re: Block at a time ... |
Дата | |
Msg-id | op.u9zlqp0reorkce@localhost обсуждение исходный текст |
Ответ на | Re: Block at a time ... (Scott Carey <scott@richrelevance.com>) |
Ответы |
Re: Block at a time ...
|
Список | pgsql-performance |
>> This is one of the more-or-less solved problems in Unix/Linux. Ext* >> file systems have a "reserve" usually of 10% of the disk space that >> nobody except root can use. It's not for root, it's because with 10% >> of the disk free, you can almost always do a decent job of allocating >> contiguous blocks and get good performance. Unless Postgres has some >> weird problem that Linux has never seen before (and that wouldn't be >> unprecedented...), there's probably no need to fool with >> file-allocation strategies. >> >> Craig > > Its fairly easy to break. Just do a parallel import with say, 16 > concurrent tables being written to at once. Result? Fragmented tables. Delayed allocation (ext4, XFS) helps a lot for concurrent writing at a medium-high rate (a few megabytes per second and up) when lots of data can sit in the cache and be flushed/allocated as big contiguous chunks. I'm pretty sure ext4/XFS would pass your parallel import test. However if you have files like tables (and indexes) or logs that grow slowly over time (something like a few megabytes per hour or less), after a few days/weeks/months, horrible fragmentation is an almost guaranteed result on many filesystems (NTFS being perhaps the absolute worst).
В списке pgsql-performance по дате отправления: