>
> # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d
> # agcount=4
>
> # mount -o logbsize=256k
> and that those would be upcoming new defaults for mkfs.
>
> 4 ags may not be what you want for a ~2T filesystem.
Showing posts with label xfs. Show all posts
Showing posts with label xfs. Show all posts
Thursday, January 28, 2010
mkfs.xfs optimize
> David mentioned these before as a generic place to start:
>
> # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d
> # agcount=4
>
> # mount -o logbsize=256k
>
> and that those would be upcoming new defaults for mkfs.
>
> 4 ags may not be what you want for a ~2T filesystem.
http://everything2.com/title/Filesystem+performance+tweaking+with+XFS+on+Linux
>
> # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d
> # agcount=4
>
> # mount -o logbsize=256k
> and that those would be upcoming new defaults for mkfs.
>
> 4 ags may not be what you want for a ~2T filesystem.
XFS: маленький, но неприятный глючок
Может быть, обращали внимание на такую вещь: удаление множества файлов в linux на XFS-разделах проходит ненормально долго.
Проблема оказалась легко решаемой. Для того, чтобы избавиться от этой досадной «особенности», необходимо указать следующие опции монтирования файловой системы XFS:
rw,noatime,nodiratime,logbufs=8,logbsize=256k,noquota
При этом, если ФС смонтирована, недостаточно команды
mount ... -o remount
нужно «по-честному» отмонтировать и примонтировать раздел (или перезагрузить машину, если это корневая файловая система). Кроме того, необходимо выполнить команду xfs_admin -j <раздел> для перехода на вторую версию формата логов. Правда, у меня на SLES10SP2 система сказала, что это лишнее:
flycat:~ # xfs_admin -j /dev/sdb1
version 2 log format is already in use
versionnum [0xb4a4+0x8] = V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2
Замечу, что такая конфигурация будет потреблять больше оперативки (примерно на пару мегабайт на файловую систему), но кто в наше время учитывает такие мелочи?
Improving XFS unlink() performance
I knew for quite some time that XFS has an abysmal performance on huge deletes - e.g. deleting a Linux kernel source tree can take several minutes. But when I had to do multiple images with kiwi yesterday on my relatively new server machine at home, it started to really annoy me, so I invested some time to find out if there is a way to improve the situation.
This is what I started from (numbers are from bonnie++):
/dev/sda1 /space3 xfs rw,noatime,nodiratime,noquota 0 0
Version 1.01d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
server 4G 69024 31 71616 10 32732 6 75462 39 77511 6 120.9 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 341 1 +++++ +++ 311 1 340 2 +++++ +++ 249 1
The first hint I got from a colleague was to use “logbufs=8″ mount option. This increases the number of buffers that XFS uses for its log. Whatever that means. At the first try, it did not change anything until I realized that a “mount -o remount,…” was not enough, I had to unmount and newly mount the filesystem with the option to make it work.
This is the result, still not too impressive with regard to delete performance, the difference might be purely statistical noise:
/dev/sda1 /space3 xfs rw,noatime,nodiratime,logbufs=8,noquota 0 0
bonnie++:
Version 1.01d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
server 4G 66413 31 68420 10 32467 5 76001 40 77143 6 107.2 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 338 2 +++++ +++ 313 1 332 2 +++++ +++ 269 1
But the really good results came only after also increasing the logbuffer size with the “logbsize=262144″ option:
/dev/sda1 /space3 xfs rw,noatime,nodiratime,logbufs=8,logbsize=256k,noquota 0 0
Version 1.01d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
server 4G 77932 33 85196 10 32134 6 59205 32 76792 6 184.5 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1495 5 +++++ +++ 848 2 1468 7 +++++ +++ 916 3
Now that’s a real improvement and I’ll keep it like that.
But beware, there are some caveats:
* The file system has to support the larger buffer sizes, which means you need a sufficiently new kernel. As I am running openSUSE 11.1 on this machine, this is not really a problem, but I had to enable the “version 2 log format” with “xfs_admin -j /dev/sda1″ because this partition was created using SLES10 and I am not sure if I still would be able to mount it on an old machine.
* It will use more memory. I guess that it needs at least 2 MB (256kB * 8 buffers) per filesystem, probably more. But on a box with 2GB of RAM, I’ll gladly spare that for better performance.
One note: those “measurements” were taken on a Core2 Duo machine using an abit IP35-E mainboard. The used disk drive was my old Maxtor STM3500630A 500GB IDE drive. I did not do any statistical corrections etc., so your mileage may vary.
Проблема оказалась легко решаемой. Для того, чтобы избавиться от этой досадной «особенности», необходимо указать следующие опции монтирования файловой системы XFS:
rw,noatime,nodiratime,logbufs=8,logbsize=256k,noquota
При этом, если ФС смонтирована, недостаточно команды
mount ... -o remount
нужно «по-честному» отмонтировать и примонтировать раздел (или перезагрузить машину, если это корневая файловая система). Кроме того, необходимо выполнить команду xfs_admin -j <раздел> для перехода на вторую версию формата логов. Правда, у меня на SLES10SP2 система сказала, что это лишнее:
flycat:~ # xfs_admin -j /dev/sdb1
version 2 log format is already in use
versionnum [0xb4a4+0x8] = V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2
Замечу, что такая конфигурация будет потреблять больше оперативки (примерно на пару мегабайт на файловую систему), но кто в наше время учитывает такие мелочи?
Improving XFS unlink() performance
I knew for quite some time that XFS has an abysmal performance on huge deletes - e.g. deleting a Linux kernel source tree can take several minutes. But when I had to do multiple images with kiwi yesterday on my relatively new server machine at home, it started to really annoy me, so I invested some time to find out if there is a way to improve the situation.
This is what I started from (numbers are from bonnie++):
/dev/sda1 /space3 xfs rw,noatime,nodiratime,noquota 0 0
Version 1.01d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
server 4G 69024 31 71616 10 32732 6 75462 39 77511 6 120.9 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 341 1 +++++ +++ 311 1 340 2 +++++ +++ 249 1
The first hint I got from a colleague was to use “logbufs=8″ mount option. This increases the number of buffers that XFS uses for its log. Whatever that means. At the first try, it did not change anything until I realized that a “mount -o remount,…” was not enough, I had to unmount and newly mount the filesystem with the option to make it work.
This is the result, still not too impressive with regard to delete performance, the difference might be purely statistical noise:
/dev/sda1 /space3 xfs rw,noatime,nodiratime,logbufs=8,noquota 0 0
bonnie++:
Version 1.01d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
server 4G 66413 31 68420 10 32467 5 76001 40 77143 6 107.2 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 338 2 +++++ +++ 313 1 332 2 +++++ +++ 269 1
But the really good results came only after also increasing the logbuffer size with the “logbsize=262144″ option:
/dev/sda1 /space3 xfs rw,noatime,nodiratime,logbufs=8,logbsize=256k,noquota 0 0
Version 1.01d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
server 4G 77932 33 85196 10 32134 6 59205 32 76792 6 184.5 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1495 5 +++++ +++ 848 2 1468 7 +++++ +++ 916 3
Now that’s a real improvement and I’ll keep it like that.
But beware, there are some caveats:
* The file system has to support the larger buffer sizes, which means you need a sufficiently new kernel. As I am running openSUSE 11.1 on this machine, this is not really a problem, but I had to enable the “version 2 log format” with “xfs_admin -j /dev/sda1″ because this partition was created using SLES10 and I am not sure if I still would be able to mount it on an old machine.
* It will use more memory. I guess that it needs at least 2 MB (256kB * 8 buffers) per filesystem, probably more. But on a box with 2GB of RAM, I’ll gladly spare that for better performance.
One note: those “measurements” were taken on a Core2 Duo machine using an abit IP35-E mainboard. The used disk drive was my old Maxtor STM3500630A 500GB IDE drive. I did not do any statistical corrections etc., so your mileage may vary.
Thursday, August 20, 2009
Рекомендации по выбору файловых систем для конкретных задач
Рекомендации по выбору файловых систем для конкретных задач
Обслуживание элементов оформелния страниц, хелперов - хранение большого количества мелких файлов распределённых по разным директориям, чтение большого количества файлов при обслуживании пользовательского запроса.
Для данной задачи рекомендуется использование raid уровня 0 (или 10).
Наибольшую производительность для такой задачи показывает файловая система reiserfs версии 4 и выше.
Следом идёт файловая система XFS, в интернете имеется достаточно информации по тюнингу данной файловой системы для работы с большим количеством файлов (искать по запросу "tune XFS").
Пример 13.1. Настройка XFS для большого количества мелких файлов
Опции для создания: -f -d sunit=128,swidth=512,unwritten=1 -l version=2,sunit=128
Опции для монтирования: noatime,largeio,ihashsize=131072,attr2,barrier,allocsize=1073741824
Следом идёт файловая система JFS.
База данных Postgresql
Выбор файловой системы для базы Postgresql пока является личным делом администратора сервера. Однако этот выбор должен быть основан на серии экспериментов.
Имеются хорошие отзывы о получении значительного роста производительность после перехода с различных файловых систем на reiserfs и zfs. Это объясняется наличием встроенного сжатия данных и, соответственно, повышением количества прочитанных данных, при той же скорости физического чтения с диска. Однако, очевидно, что декомпрессия данных требует дополнительных затрат процессорного времени.
Советы по оптимизации Postgsql можно найти в разделе ???.
Обслуживание элементов оформелния страниц, хелперов - хранение большого количества мелких файлов распределённых по разным директориям, чтение большого количества файлов при обслуживании пользовательского запроса.
Для данной задачи рекомендуется использование raid уровня 0 (или 10).
Наибольшую производительность для такой задачи показывает файловая система reiserfs версии 4 и выше.
Следом идёт файловая система XFS, в интернете имеется достаточно информации по тюнингу данной файловой системы для работы с большим количеством файлов (искать по запросу "tune XFS").
Пример 13.1. Настройка XFS для большого количества мелких файлов
Опции для создания: -f -d sunit=128,swidth=512,unwritten=1 -l version=2,sunit=128
Опции для монтирования: noatime,largeio,ihashsize=131072,attr2,barrier,allocsize=1073741824
Следом идёт файловая система JFS.
База данных Postgresql
Выбор файловой системы для базы Postgresql пока является личным делом администратора сервера. Однако этот выбор должен быть основан на серии экспериментов.
Имеются хорошие отзывы о получении значительного роста производительность после перехода с различных файловых систем на reiserfs и zfs. Это объясняется наличием встроенного сжатия данных и, соответственно, повышением количества прочитанных данных, при той же скорости физического чтения с диска. Однако, очевидно, что декомпрессия данных требует дополнительных затрат процессорного времени.
Советы по оптимизации Postgsql можно найти в разделе ???.
Subscribe to:
Posts (Atom)