| Нужна ли дефрагментация? |
Dec. 28th, 2007|07:21 am |
Несмотря на печальные события, связанные с расправой над дважды оправданных судом присяжных военными Аракчеевым и Худяковым, я всё же на сугубо техническую тему хотел написать. Про фрагментацию в Линуксе и нужно ли с ней бороться.
На крысятнике пользователи возбудились на тему - Существенно ли сказывается на производительности фрагментация файловой системы Линукса и нужно ли с ней бороться? Напомню, что в отличии от Вендовся, в Линуксе специализированных дефрагментаторов нет, поскольку справедливо считается, что используемые там файловые системы в нормальном режиме (т.е. когда диск у вас не забит под завязку) фрагментируются слабо. Более того, есть определенные соображения на тему того, что в многозадачной среде фрагментация (даже если она есть) слабо сказывается на производительности, в отличии от какого-нибудь однозадачного ДОСа. Действительно, в многозадачной среде несколько программ могут практически одновременно обращаться к диску, причём к разным его частям, и поэтому типичное рассуждение про позиционирование считывающих головок на твердом диске тут неприменимо. Есть также соображения, что и на NTFS фрагментация не приводит к падению производительности, а продвижение M$-ом своих дефрагментаторов есть простой маркетинговый buzz. Типа, пользователь хочет иметь дефрагментатор - компания ему этот дефрагментатор обеспечивает.
В то же время есть много свидетельств от разных людей, которые утверждают, что примитивная дефрагментация с помощью перемещения файлов существенно улучшает производительность. (В качестве справки - ссылка на блог MooSE, где он собрал парочку скриптов, демонстрирующих, как это делается http://ylsoftware.com/?action=news&na=viewfull&news=379 ). Правда, никаких бенчмарков, демонстрирующих прирост производительности, при этом обычно не приводится, так что тут ситуация полностью как с НЛО, приходится верить на слово.
Я решил восполнить пробел.
Поскольку я недавно приобрел большой диск, то я решил перенести на него раздел /usr. До этого у меня был 20ГБ диск, полностью отданный под / (вместе с /usr). Диск забит под завязку, df сообщает о 100% занятости. Полностью измерение фрагментации на нем мне лень проводить, но очевидно она большая, а несколько ниже будет приведена парочка цифр, подтверждающих это. Диск довольно медленный, hdparm -t показывает примерно 20 МБ/с. Новый же диск (SATA 250ГБ) гораздо быстрее, у него порядка 70 МБ/c. Поэтому для бенчмарка я сделал на нем два раздела. На первый раздел я перенес /usr с помощью команды "mount /dev/sda2 /mnt/hd ; cd /usr ; cp -a ./ /mnt/hd", а на второй залил раздел целиком с помощью "dd if=/dev/hdb2 of=/dev/sda4". Понятно, что при копировании с помощью cp файловая система по ходу дела дефрагментируется (этот раздел будем называть копией), а при копировании с помощью dd, она переносится в том виде, в каком была (этот раздел назовем снимком). Тем самым избавляемся от влияния разности скорости дисков. При перезагрузке либо вручную монтирую копию в /usr, либо монтирую снимок в любой свободный каталог, а потом делаю ссылку /usr на поддиректорию usr в этом каталоге. Файловая система - Reiser3 (её автор, как многие помнят, тоже под следствием по сомнительному поводу).
Я не хочу измерять производительность с помощью простого find, поскольку не хочется тупо мерить скорость файловой системы, а наоборот есть желание воспроизвести обычную рабочую обстановку.
Для этой цели использовался старт среды статистического анализа R. У меня в автозагрузке для этой среды стоит подгрузка дополнительных модулей stats и utils, пакета RGtk2 (обертка для графической библиотеки Gtk2, которое тянет за собой граф-либу cairo, всё это довольно увесистое). Т.е., как мне кажется, многозадачность тут используется в полной мере - много вызовов Хlib одновременно с загрузкой математических библиотек. Как только это все поднимется, то запускается скрипт с единственным вызовом quit(save="no"), после чего снимаются показания секундомера.
Кстати, на тему фрагментации. На разделе-снимке фрагментация библиотеки RGtk2.so весьма прилична (или, скорее, неприлична):
$sudo /sbin/filefrag /usr/lib/R/library/RGtk2/libs/RGtk2.so
/usr/lib/R/library/RGtk2/libs/RGtk2.so: 299 extents found
$ls -lA /usr/lib/R/library/RGtk2/libs/RGtk2.so
-rwxr-xr-x 1 root root 7456747 2007-09-06 01:03 /usr/lib/R/library/RGtk2/libs/RGtk2.so*
Ну, что ж, теперь результаты. Вот с чего я начал (вся система на старом диске):
$time R --no-save < quit.R
R version 2.5.1 (2007-06-27)
Copyright (C) 2007 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
Loading required package: RGtk2
Loading required package: cairoDevice
Loading required package: grid
Loading required package: grDevices
[Previously saved workspace restored]
During startup - Warning message:
'length(family)' differs between new and previouscharacter(0)
> quit(save="no")
real 0m11.932s
user 0m4.100s
sys 0m0.110s
После второго запуска (я опускаю welcome-message программы R):
real 0m4.191s
user 0m4.060s
sys 0m0.070s
real, понятно, и должен быть меньше, поскольку все библиотеки уже загружены в память.
Следующий этап: перезагрузка, и то же самое с /usr в виде линка на usr с раздела-снимка (т.е. фрагментация та же, но диск уже новый).
Первый запуск:
real 0m6.726s
user 0m4.080s
sys 0m0.110s
Второй:
real 0m4.237s
user 0m4.040s
sys 0m0.060s
За счет более быстрого диска имеем внушительное ускорение первого запуска и практически неизменный - второй. В принципе, ничего удивительного.
И третий опыт, перезагрузка и копия подмонтирована в качестве /usr (т.е. раздел на новом диске, дефрагментированный подручными средствами):
Первый запуск:
real 0m5.613s
user 0m4.040s
sys 0m0.160s
Второй:
real 0m4.149s
user 0m4.050s
sys 0m0.050s
Вывод таков. Разумеется от дефрагментации польза есть, но она не настолько велика ( учитывая в каком состоянии файловая система находилась у меня до этого - 300 обрывков на 8 мегабайтном файле), чтобы лишний раз париться с дефрагментацией. |
|