Всем привет.
Стоит на сервере FreeBSD 7.2 amd64.
В сервере два идентичных SATA харда по 1ТБ.
Используется gmirror для RAID1.
# gmirror list
Geom name: gm0
State: COMPLETE
Components: 2
Balance: round-robin
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 1010752839
Providers:
1. Name: mirror/gm0
Mediasize: 1000204885504 (932G)
Sectorsize: 512
Mode: r5w5e6
Consumers:
1. Name: ad0
Mediasize: 1000204886016 (932G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: DIRTY
GenID: 0
SyncID: 1
ID: 3257944739
2. Name: ad2
Mediasize: 1000204886016 (932G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: DIRTY
GenID: 0
SyncID: 1
ID: 3627728499
Сервер используется для веб-сайта с посещаемостью ~40-50k посетителей.
Много статики: аватарки, фотографии из галерей и прочее.
Из ПО стоит mysql5, php5.2 (php-fpm), nginx 0.8.54.Проблема, а точнее вопрос в следующем.
Когда набираю gstat, то вижу следующую ситуацию:
dT: 1.006s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
136 315 2 20 257.0 313 6538 827.8 99.8| ad0
82 367 1 16 114.2 366 7779 820.9 100.0| ad2
0 0 0 0 0.0 0 0 0.0 0.0| ad0s1
137 316 3 36 209.4 313 6538 828.6 99.8| mirror/gm0
0 18 18 215 0.0 0 0 0.0 0.1| md2
0 0 0 0 0.0 0 0 0.0 0.0| ad2s1
137 316 3 36 209.4 313 6538 829.1 99.8| mirror/gm0s1
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1a
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1b
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1c
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1d
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1e
137 316 3 36 209.5 313 6538 829.4 99.8| mirror/gm0s1fТакая ситуация чередуется со следующей:
L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
3 55 55 739 12.8 0 0 0.0 51.4| ad0
0 57 57 757 15.6 0 0 0.0 58.7| ad2
0 0 0 0 0.0 0 0 0.0 0.0| ad0s1
3 111 111 1496 14.5 0 0 0.0 75.5| mirror/gm0
0 848 120 1373 0.2 727 11373 4.6 3.9| md2
0 0 0 0 0.0 0 0 0.0 0.0| ad2s1
3 111 111 1496 14.5 0 0 0.0 75.6| mirror/gm0s1
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1a
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1b
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1c
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1d
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1e
3 111 111 1496 14.6 0 0 0.0 75.9| mirror/gm0s1f
Иногда %busy падает до 10-20, но это рано утром.
Днем держится больше 60-70, а вечером всегда 100%.
Сделал диск в памяти (md2) на 4гб, туда нгинкс записывет горячую статику, каждые полчаса диск подчищается.
Без диска ситуацию еще хуже, в gstat'e почти всегда 100%.Вот топ в момент нагрузки по gstat'у 100%.
# top -m io -o total
last pid: 29257; load averages: 3.13, 3.48, 3.47
146 processes: 10 running, 121 sleeping, 15 waiting
CPU: 27.9% user, 0.0% nice, 7.2% system, 0.7% interrupt, 64.1% idle
Mem: 4730M Active, 2152M Inact, 713M Wired, 185M Cache, 399M Buf, 108M Free
Swap: 4096M Total, 432K Used, 4095M FreePID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
51 root 2 7 0 357 0 357 42.00% syncer
26704 www 1124 136 134 51 0 185 21.76% nginx
26705 www 2035 98 120 13 0 133 15.65% nginx
829 mysql 2742 974 5 4 0 9 1.06% mysqld
29167 www 292 172 4 0 0 4 0.47% php-cgi
29193 www 264 111 3 0 0 3 0.35% php-cgi
29023 www 277 193 2 0 0 2 0.24% php-cgiЗакономерность следующая, когда в gstat все зеленое (до 50%), то в топе два воркера nginx'а кушают около 10-20%, все окей.
Однако когда в gstat'е поднимается до 100%, то топ показывает >80% на процессе syncer.теперь iostat:
# iostat -w 1
tty ad0 ad2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 1062 33.70 132 4.35 33.53 133 4.36 20 0 5 1 75
0 652 33.92 74 2.44 38.22 80 2.97 51 0 13 3 33
0 586 32.44 113 3.59 30.43 111 3.31 70 0 14 3 13
0 562 27.69 83 2.26 30.32 87 2.59 69 0 17 2 12
0 576 32.21 93 2.94 34.35 97 3.27 48 0 12 3 37
0 592 24.29 88 2.10 26.15 92 2.36 22 0 5 2 71
0 583 42.11 125 5.15 41.31 109 4.41 23 0 9 2 66
0 541 20.16 64 1.25 25.75 78 1.97 19 0 7 1 73
0 528 17.20 97 1.64 16.15 95 1.50 26 0 5 1 68
0 519 6.86 573 3.84 6.86 573 3.84 10 0 3 1 85
0 558 24.55 79 1.91 25.11 80 1.97 23 0 6 2 68
0 554 19.26 91 1.72 19.91 91 1.78 14 0 6 2 78
0 547 26.82 97 2.55 28.62 99 2.78 26 0 6 1 67
0 584 11.68 81 0.93 13.39 81 1.07 10 0 3 2 85
0 610 18.08 72 1.26 16.44 72 1.15 15 0 4 1 80
0 510 19.23 57 1.06 17.96 57 0.99 22 0 6 1 71
0 586 39.15 61 2.32 34.03 58 1.92 19 0 5 1 75
0 534 20.92 24 0.49 19.25 24 0.45 12 0 3 1 85
0 537 19.27 30 0.56 22.41 29 0.63 14 0 4 1 81
0 553 16.25 48 0.76 13.21 48 0.62 17 0 4 1 77
0 480 16.40 40 0.64 15.18 39 0.57 22 0 4 0 74
0 502 19.43 63 1.19 22.48 66 1.44 18 0 3 0 78
0 593 10.45 22 0.22 17.64 22 0.38 23 0 5 1 71
0 591 21.47 86 1.81 23.40 85 1.95 26 0 6 2 66
0 592 18.65 97 1.77 18.55 97 1.76 27 0 6 1 66
0 534 21.63 145 3.06 21.14 144 2.97 14 0 5 2 79
0 560 16.30 33 0.52 18.06 33 0.58 16 0 3 1 80
0 505 16.26 758 12.04 16.35 778 12.42 8 0 5 2 86
0 537 16.00 310 4.84 16.00 322 5.03 0 0 0 0 99
0 353 16.00 298 4.66 16.00 309 4.83 0 0 1 0 99
0 363 24.30 339 8.04 24.92 362 8.80 0 0 0 1 99
0 332 20.38 334 6.64 18.95 306 5.66 1 0 1 0 99
0 343 18.62 291 5.29 18.01 307 5.40 8 0 3 0 89
0 462 19.44 293 5.56 21.84 241 5.15 18 0 3 1 79
0 552 36.00 57 1.99 34.60 57 1.91 71 0 16 2 11
0 540 15.56 94 1.43 17.98 103 1.82 70 0 16 2 12
0 572 25.52 99 2.48 28.06 102 2.80 21 0 6 2 72
0 583 42.38 100 4.15 36.46 86 3.08 22 0 6 1 71
0 508 27.89 76 2.06 28.40 75 2.07 20 0 6 1 73
0 498 56.06 155 8.49 54.32 153 8.12 13 0 5 1 82
0 489 25.43 49 1.21 26.61 49 1.27 17 0 5 2 76
0 536 15.60 80 1.23 15.43 80 1.21 26 0 8 1 65
0 529 8.82 342 2.94 8.74 340 2.90 24 0 6 1 69
0 532 13.12 50 0.64 11.80 49 0.56 16 0 4 1 79
0 530 21.39 79 1.64 19.40 79 1.51 32 0 9 1 59
0 560 17.15 71 1.18 17.86 69 1.20 14 0 5 1 79
0 573 24.71 76 1.82 35.08 92 3.16 18 0 6 0 75
0 684 20.26 84 1.67 18.32 81 1.46 31 0 6 2 61
0 568 11.05 79 0.86 10.73 79 0.83 28 0 6 2 64
0 569 21.92 94 2.02 25.18 96 2.37 23 0 6 2 68Так вот хочется понять, нормальная ли это ситуация или здесь явно проблема и следует ли искать узкое место?
Сайт периодически задумывается на секунду-две, хочется понять, в дисках ли дело?
если смотреть top, то там частенько один из процессов nginx'а висит в biord'е - это же свидетельствует о проблемах с диском?
в nginx'е включал open_file_cache, по-разному пробовал его конфигурировать -- ситуация толком не меняется.
пробовал в нгинксе отключать все картинки из галерей пользователей, т.е. возвращать 404, если запрашивается картинка из папки с фотографями. Нагрузка сильно падает по gstat'у, держится около 20-30%. то есть можно сказать, что дело именно в статике и именно в большом кол-ве фотографий.
Папка с фотогорафями разбита на подпапки, по айдишнику. То есть фото из галереи 123456 лежит в папке /12/34/56/.
надо сказать, что правильный путь к картинке делает сам нгинкс спомозью регулярки. То есть у юзера в src картинки прописано "site.ru/img/123456/ab.jpg", а нгинкс преобразует к "/img/12/34/56/ab.jpg". но ведь пара регулярок в конфиге нгинкса не могут быть причиной этих проблем?Всем заранее спасибо за ответы!
да, искать узкое место следуетP.S. а памяти сколько и какие файловые системы в ходу?
> да, искать узкое место следует
> P.S. а памяти сколько и какие файловые системы в ходу?Памяти - 8ГБ, ФС используется ufs.
> Так вот хочется понять, нормальная ли это ситуация или здесь явно проблема
> и следует ли искать узкое место?Ну вообще-то 100% загрузки диска, это говорит не о том, что он тормозит по какой-то причине, а о том, что он пашет как папа карло и не справляется с нагрузкой. Модернизируйте дисковую подсистему, либо берите приличный дисковый контроллер с массивом, ну либо бюджетный вариант, вместо 2 х 1TB - Raid1, сделайте например 4 х 500MB - Raid10 ( GMirror попарно + GStripe) либо еще меньше 8x250, чтобы увеличить кол-во работающих винтов, при сохранении результирующего объема, тогда нагрузка будет сильнее размазываться по ним, а не концентрироваться на двух.
2. У Вас вся нагрузка на FS mirror/gm0s1f, подозреваю, что там и база мускля и сами данные веба, неплохо бы разнести, да и вообще систему надо поставить отдельно, а не на винты с данными.
>[оверквотинг удален]
> тормозит по какой-то причине, а о том, что он пашет как
> папа карло и не справляется с нагрузкой. Модернизируйте дисковую подсистему, либо
> берите приличный дисковый контроллер с массивом, ну либо бюджетный вариант, вместо
> 2 х 1TB - Raid1, сделайте например 4 х 500MB -
> Raid10 ( GMirror попарно + GStripe) либо еще меньше 8x250, чтобы
> увеличить кол-во работающих винтов, при сохранении результирующего объема, тогда нагрузка
> будет сильнее размазываться по ним, а не концентрироваться на двух.
> 2. У Вас вся нагрузка на FS mirror/gm0s1f, подозреваю, что там и
> база мускля и сами данные веба, неплохо бы разнести, да и
> вообще систему надо поставить отдельно, а не на винты с данными.1. варианта железной модернизации пока что нет.
2. на gm0s1f как раз находится статика, т.е. папка с фотографиями.
отключаю выдача фото в нгинксе -- сразу падает нагрузка этого раздела практически до нуля.
> 1. варианта железной модернизации пока что нет.Если так, то я бы пробовал:
1. использовать 'load' balancing mode для gmirror. После r200286 для RELENG7 этот метод баллансировки отслеживает положение головок при выборе диска, что позволяет снизить временнЫе затраты на перепозиционировании. Т.е. load должен показать результаты лучше, чем round-robin. Для этой вкусности придётся обновиться хотябы до 7.3.
2. задействовать AHCI (что потребует перехода как минимум на RELENG8, со всеми вытекающими неудобствами обновления)И два вопроса:
- в первом выводе gstat у вас 300 операций записи в секунду. Кто источник этих операций?
- файловые системы смонтированы с ключиком noatime?
>[оверквотинг удален]
> 1. использовать 'load' balancing mode для gmirror. После r200286 для RELENG7 этот
> метод баллансировки отслеживает положение головок при выборе диска, что позволяет снизить
> временнЫе затраты на перепозиционировании. Т.е. load должен показать результаты лучше,
> чем round-robin. Для этой вкусности придётся обновиться хотябы до 7.3.
> 2. задействовать AHCI (что потребует перехода как минимум на RELENG8, со всеми
> вытекающими неудобствами обновления)
> И два вопроса:
> - в первом выводе gstat у вас 300 операций записи в секунду.
> Кто источник этих операций?
> - файловые системы смонтированы с ключиком noatime?1. а как узнать, кто источник операций? или только через top?
2. нет, не смонтированы. существенный прирост дает?
> 1. а как узнать, кто источник операций? или только через top?top как вы его уже использовали (top -m io -o total) разделяет операции чтения и записи - более удобного способа найти источник записей я не знаю.
Есть подозрение, что сам нгинкс создаёт большое количество write iops - если это так, то первое, что приходит в голову - логи. Полезно будет проверить, уменьшится ли количество записей если вы временно отключите логи. Если дело в них - убедитесь, что параметр buffer указан/используется для логов.Вообще про операции записи я заговорил только потому, что в один из двух выводов iostat , которые привели вы, операции записи составляли более 99 процентов. Если это случайность и данная картина совсем не характерна серверу, то можно дальше не углубляться. Однако если процент операций записи высок, то было бы неплохо разобраться в их источнике.
> 2. нет, не смонтированы. существенный прирост дает?
обычно прирост незначительный - от нескольких процентов до десяти, но всё зависит от характера дисковых операций / данных хранимых на диске.
Самый большой overhead в процентном соотношении будет если мы работаем с большим количеством малюсеньких файлов и файлы постоянно различны. Если мы например прочитали сотню крохотных файлов, то это грубо говоря сто операций чтения. Однако если atime включён, то это ещё 100 дополнительных операций записи (обновить access time для каждого из файлов). Т.е. 50 процентов по количеству iops.
Низкий overhead в процентном соотношении - при работе с большими файлами, потому как операций чтения становится больше, операций записи - как и в предыдущем примере.
Практически незаметный overhead - при работе с одним и тем-же набором фалов. Происходит из-за механизма soft updates в контексте ufs - т.е. операция записи изначально откладывается во времени, а после "отменяется" следующей операцией обновления access time (для этого же файла).
Если у вас нет программного обеспечения, зависящего от access time (встречается крайне редко), то я бы рекомендовал монтировать файловые системы с noatime (как минимум те, что под высокой нагрузкой).
> в nginx'е включал open_file_cache, по-разному пробовал его конфигурировать -- ситуация
> толком не меняется.
> пробовал в нгинксе отключать все картинки из галерей пользователей, т.е. возвращать 404,
> если запрашивается картинка из папки с фотографями. Нагрузка сильно падает по
> gstat'у, держится около 20-30%. то есть можно сказать, что дело
> именно в статике и именно в большом кол-ве фотографий.
>Mem: 4730M Active, 2152M Inact, 713M Wired, 185M Cache, 399M Buf, 108M FreeИсходя из собственного понимания мира, могу предположить что оперативка системы не используется для файлового кеширования. Да и в данный момент 2152M Inact.... Печально :-)
Во фряхе без дополнительного тюнинга с этим делом плоховато, в отличие от линуха, который всю оперативку под файловый кеш отдает легко и непринужденно (и по умолчанию).
Именно поэтому вам приходится делать "диски в оперативке под горячую статику". Это, на мой взгляд, весьма грустный костыль.
---
кроме того, возможно требуется больше памяти отдать под кеш таблиц мускула. Тогда он уменьшит число обращений к диску, будет отдавать ответы быстрее, и число процессов пыхпе уменьшится. Соответственно, высвободится еще оперативка.
Кроме того, я бы рекомендовал вынести БД на отдельные диски, чтобы она не воевала за seek-и - будет отвечать еще быстрее.
Хотя, скорее всего, в этом особого выигрыша добиться не удастся, поскольку под пхп+мускул у вас используется всего 700 Мб ОЗУ (да еще минус системные процессы).
-------
>Сделал диск в памяти (md2) на 4гб, туда нгинкс записывет горячую статику, каждые полчаса >диск подчищается.ПОДчищается или полностью зануляется?
> Исходя из собственного понимания мира, могу предположить что оперативка системы не используется
> для файлового кеширования. Да и в данный момент 2152M Inact.... Печально
> :-)Вы не правы. Inact в данном случае какраз показывает объём данных находящихся в дисковом кэше.
>> Исходя из собственного понимания мира, могу предположить что оперативка системы не используется
>> для файлового кеширования. Да и в данный момент 2152M Inact.... Печально
>> :-)
> Вы не правы. Inact в данном случае какраз показывает объём данных находящихся
> в дисковом кэше.Ткните меня, пожалуйста, в соответствующую документацию.
> Ткните меня, пожалуйста, в соответствующую документацию.Документацию на взлёт не подскажу, но приведённый ниже пример подтверждает мои слова.
ground# grep land3 /etc/fstab
/dev/ada1s2e /land3 ufs rw,noatime,noauto 2 2
ground# mount /land3
ground# du -hs /land3/test.avi
1.1G /land3/test.avi
ground# top -b | sed /Inact/\!d
Mem: 120M Active, 211M Inact, 241M Wired, 2068K Cache, 199M Buf, 2921M Free
ground# time cat /land3/test.avi > /dev/null
0.083u 1.160s 0:10.02 12.3% 10+5195k 9361+0io 0pf+0w
ground# top -b | sed /Inact/\!d
Mem: 119M Active, 1226M Inact, 389M Wired, 2052K Cache, 199M Buf, 1760M Free
ground# time cat /land3/test.avi > /dev/null
0.023u 0.870s 0:00.89 100.0% 10+4988k 0+0io 0pf+0w
ground#
>[оверквотинг удален]
> Free
> ground# time cat /land3/test.avi > /dev/null
> 0.083u 1.160s 0:10.02 12.3% 10+5195k 9361+0io 0pf+0w
> ground# top -b | sed /Inact/\!d
> Mem: 119M Active, 1226M Inact, 389M Wired, 2052K Cache, 199M Buf, 1760M
> Free
> ground# time cat /land3/test.avi > /dev/null
> 0.023u 0.870s 0:00.89 100.0% 10+4988k 0+0io 0pf+0w
> ground#
>
Угум, хороший пример, спасибо.
>[оверквотинг удален]
> Free
> ground# time cat /land3/test.avi > /dev/null
> 0.083u 1.160s 0:10.02 12.3% 10+5195k 9361+0io 0pf+0w
> ground# top -b | sed /Inact/\!d
> Mem: 119M Active, 1226M Inact, 389M Wired, 2052K Cache, 199M Buf, 1760M
> Free
> ground# time cat /land3/test.avi > /dev/null
> 0.023u 0.870s 0:00.89 100.0% 10+4988k 0+0io 0pf+0w
> ground#
>а там это, всякие специфические опции в loader.conf (KVA или что там...) - тюненые ?
> а там это, всякие специфические опции в loader.conf (KVA или что там...)
> - тюненые ?Ядро собрано с KVA_PAGES=512, и в loader.conf есть vm.kmem_size_max="1400M". Оба параментра влияют на адресное пространство ядра и в моём понимании не будут влиять на работу дискового кэша. Если хотите - могу повторить опыт убрав эти параметры.
>> а там это, всякие специфические опции в loader.conf (KVA или что там...)
>> - тюненые ?
> Ядро собрано с KVA_PAGES=512, и в loader.conf есть vm.kmem_size_max="1400M". Оба параментра
> влияют на адресное пространство ядра и в моём понимании не будут
> влиять на работу дискового кэша. Если хотите - могу повторить опыт
> убрав эти параметры.А на что они тогда влияют?
Повторить опыт - если не сложно - было бы интересно, просто у меня нет быстрой возможности его провести.Спасибо за "ликбез" :-)
> Повторить опыт - если не сложно - было бы интересно, просто у
> меня нет быстрой возможности его провести.Результат без дополнительных параметров в ядре и loader.conf значительных отличий не имеет:
ground# mount /land3
ground# du -hs /land3/test.avi
1.1G /land3/test.avi
ground# top -b | sed /Inact/\!d
Mem: 112M Active, 233M Inact, 198M Wired, 2068K Cache, 112M Buf, 2950M Free
ground# time cat /land3/test.avi > /dev/null
0.038u 1.213s 0:10.21 12.1% 10+5163k 9361+0io 0pf+0w
ground# top -b | sed /Inact/\!d
Mem: 111M Active, 1312M Inact, 281M Wired, 2024K Cache, 112M Buf, 1789M Free
ground# time cat /land3/test.avi > /dev/null
0.070u 0.841s 0:00.91 100.0% 10+5007k 0+0io 0pf+0w
>> а там это, всякие специфические опции в loader.conf (KVA или что там...)
>> - тюненые ?
> Ядро собрано с KVA_PAGES=512, и в loader.conf есть vm.kmem_size_max="1400M". Оба параментра
> влияют на адресное пространство ядра и в моём понимании не будут
> влиять на работу дискового кэша. Если хотите - могу повторить опыт
> убрав эти параметры.Ну и если Inact - это файловый кеш, не возникает ли в случае топикстартера двойного использования оперативки (двойного хранения файла в RAM) в случае использования "диска-в-памяти" md ?
> Ну и если Inact - это файловый кеш, не возникает ли в
> случае топикстартера двойного использования оперативки (двойного хранения файла в RAM)
> в случае использования "диска-в-памяти" md ?Я тоже подумал про double caching при работе с md, но автор трида упоминал, что "Без (memory) диска ситуация еще хуже, в gstat'e почти всегда 100%"
Единственное объяснение, приходящее в голову это при отключении md автор либо не дождался хоть какого-то наполнения дискового кэша, либо горячая статика нгинкса продолжала записываться на hdd, создавая дополнительную нагрузку. Или как вариант - md не был удалён и память не была возвращена "в систему".
makarov, вы не моглибы подтвердить/опровергнуть приведённые выше предположения?
> Единственное объяснение, приходящее в голову это при отключении md автор либо не
> дождался хоть какого-то наполнения дискового кэша, либо горячая статика нгинкса продолжала
> записываться на hdd, создавая дополнительную нагрузку. Или как вариант - md
> не был удалён и память не была возвращена "в систему".Да хоть 10 раз пусть кэшируется. У человека скорость меньше 10мб/с, без кэша вообще диски больше выдадут. Не такая у него и большая нагрузка, по top'у очевидно что памяти хватает. У него при 100% занятости диска идет 7 мег. в секунду, диск банально перечитывает сектора по несколько раз, так как от вибрации не может удержать головку у нужном месте.
> Да хоть 10 раз пусть кэшируется. У человека скорость меньше 10мб/с, без
> кэша вообще диски больше выдадут. Не такая у него и большая
> нагрузка, по top'у очевидно что памяти хватает. У него при 100%
> занятости диска идет 7 мег. в секунду, диск банально перечитывает сектора
> по несколько раз, так как от вибрации не может удержать головку
> у нужном месте.Если бы при линейном чтении скорость была 7 мег. в секунду, то да - это была бы проблема и я бы согласился с тем, что "диск банально перечитывает сектора по несколько раз". А в данном случае речь идёт про random i/o (из-за высокого количества параллельных запросов к зеркалу + round-robin при выборе hdd в зеркале + отсутствия ncq). Время позиционирования при ходе головки на "quarter stroke и более" будет составлять 10-30ms, так что при трёхстах операциях в секунду львинная доля времени будет потрачена на seek time.
>[оверквотинг удален]
>> случае топикстартера двойного использования оперативки (двойного хранения файла в RAM)
>> в случае использования "диска-в-памяти" md ?
> Я тоже подумал про double caching при работе с md, но автор
> трида упоминал, что "Без (memory) диска ситуация еще хуже, в gstat'e
> почти всегда 100%"
> Единственное объяснение, приходящее в голову это при отключении md автор либо не
> дождался хоть какого-то наполнения дискового кэша, либо горячая статика нгинкса продолжала
> записываться на hdd, создавая дополнительную нагрузку. Или как вариант - md
> не был удалён и память не была возвращена "в систему".
> makarov, вы не моглибы подтвердить/опровергнуть приведённые выше предположения?спасибо за ответ.
тестирование с диском в памяти продолжалось не час и не два, а пару дней.
сейчас диск в памяти вообще отключил, т.к. пользы от него не особо много.
и ситуация сейчас такая:
Mem: 721M Active, 2238M Inact, 734M Wired, 195M Cache, 399M Buf, 4001M Free
> и ситуация сейчас такая:
> Mem: 721M Active, 2238M Inact, 734M Wired, 195M Cache, 399M Buf, 4001M
> Freeесли через несколько часов мы не увидим переползания Free в Inactive, то я бы хотел посмотреть на вывод команды
sysctl -a | grep vnodes
>> и ситуация сейчас такая:
>> Mem: 721M Active, 2238M Inact, 734M Wired, 195M Cache, 399M Buf, 4001M
>> Free
> если через несколько часов мы не увидим переползания Free в Inactive, то
> я бы хотел посмотреть на вывод команды
> sysctl -a | grep vnodesпереползание видимо произошло:
Mem: 988M Active, 5781M Inact, 749M Wired, 112M Cache, 399M Buf, 258M Free# sysctl -a | grep vnodes
kern.maxvnodes: 100000
kern.minvnodes: 25000
vfs.freevnodes: 1803
vfs.wantfreevnodes: 25000
vfs.numvnodes: 87503
> переползание видимо произошлода - в этом плане всё хорошо - почти 6Гб в дисковом кэше
Может Вам попробовать ZFS + тюнинг? Только систему надо бы обновить.
Если с финансовыми ресурсами напряженка, то можно попробовать оба диска не полностью превращать в mirror. Сделать, например, три пула: один mirror, и по одному пулу на оставшихся частях дисков. И пробовать не важные файлы, но критические по скорости, размазать по эти двум пулам.
Если я правильно посчитал столбцы, то у вас очень медленная скорость работы диска? так? Причем настолько, что тюнинг, fs и т.д. не играю тут никакой роли.Сервер в стойке? Кулера уже жужжат небось, а винты десктопные? Предполагаю вибрацию и как следствие падение скорости. Решение замена винтов на серверные с защитой от вибрации. Если бюджет не позволяет, то если винты не в корзинках, проложите под болты проставки силиконовые или еще че.
> Если я правильно посчитал столбцы, то у вас очень медленная скорость работы
> диска? так? Причем настолько, что тюнинг, fs и т.д. не играю
> тут никакой роли.
> Сервер в стойке? Кулера уже жужжат небось, а винты десктопные? Предполагаю вибрацию
> и как следствие падение скорости. Решение замена винтов на серверные с
> защитой от вибрации. Если бюджет не позволяет, то если винты не
> в корзинках, проложите под болты проставки силиконовые или еще че.платформа: http://www.nix.ru/include/view-photo.html?good_id=98912&pid=...
винты: http://www.nix.ru/autocatalog/hdd_seagate/HDD_Tb_SATAII_Seag...
а какие варианты оптимальных винтов можете посоветовать?
С вибрацией хорошо справляются WD RE3 (RE4 хуже, лучше взять RE3).Винты у вас очень плохие, юзал штук 50 таких половина умерла в первые 4 месяца (хотя там помойму серия была с ошибкой в прошивке). Вибрацию они вообще не держат.
Если у вас есть возможность потушить сервер ненадолго, снимите винты и попробуйте их включить держа в руках например, чтобы вибрация не передавалась. Скорость должна выправиться.
http://www.nix.ru/autocatalog/hdd_western_digital/HDD_Tb_SAT...А вот такие подойдут в такой ситуации?
> http://www.nix.ru/autocatalog/hdd_western_digital/HDD_Tb_SAT...
> А вот такие подойдут в такой ситуации?Лотерея с маленькой вероятностью на успех. Или RE3 серия WD или ES от сегейта (но я с сегейтом стараюсь не связываться, уж очень часто нарывался на бракованные партии, то прошивка, то еще че, а уж декстопные винты их летят просто пачками :().
По мне так вам нужно:
1. включить сервер с винтами в ситуации когда на них не передается вибрация. убедиться с помощью dd например что запись на них идет в приемлемой скоростью подтвердив тем самым, что проблема в этом.
1.1. если проблема не решится загрузиться с флешки или livecd (френзи или что сейчас модно, давно BSD юзать не приходилось). Это возможно подтвердит, что проблема в настройках системы.
2. купить RE3 несмотря на цену (проверить старые винты на ошибки и спихнуть кому-нить в десктоп). вы платите за надежность. и десктопные диски могут замечательно годами работать в сервере, но вероятность этого не велика (обычно они даже быстрее серверных работают, но если условия позволяют).p.s. и еще раз повторю, я могу ошибаться, поэтому проверку считаю необходимо провести.
MiF, спасибо за сообщения, очень интересные мысли по поводу вибраций.
Сегодня потушу нгинкс и попробую погонять на скорость записи/чтения.
Чуть позже отпишу нижу по результатам тестов.
Харды заменить готов без проблем, только в этом ли проблема..
> винты: http://www.nix.ru/autocatalog/hdd_seagate/HDD_Tb_SATAII_Seag...... мдя... с этого и нужно было начинать. Тушите сервак, вытягиваете оттуда этих уродцев и в торжественной обстановке дарите их тому, кто принял решение о покупке...
Присоединяюсь к выше написанному - наплачитесь Вы с ними ...
еще некоторая информация, которая может оказаться полезной.
smartctl -a /dev/ad2
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda ES.2
Device Model: ST31000340NS
Serial Number: 9QJ4ZACA
Firmware Version: SN06
User Capacity: 1,000,204,886,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Sun Jan 23 16:55:17 2011 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSEDGeneral SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 650) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 230) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x103d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 081 063 044 Pre-fail Always - 163549760
3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 36
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 42278682
9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 10151
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 037 020 Old_age Always - 36
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 074 063 045 Old_age Always - 26 (Min/Max 22/31)
194 Temperature_Celsius 0x0022 026 040 000 Old_age Always - 26 (0 17 0 0)
195 Hardware_ECC_Recovered 0x001a 055 007 000 Old_age Always - 163549760
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0SMART Error Log Version: 1
No Errors LoggedSMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.по второму диску, ad0:
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda ES.2
Device Model: ST31000340NS
Serial Number: 9QJ4YGJQ
Firmware Version: SN06
User Capacity: 1,000,204,886,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Sun Jan 23 16:56:07 2011 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSEDGeneral SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 634) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 221) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x103d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 072 063 044 Pre-fail Always - 41270381
3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 35
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 4
7 Seek_Error_Rate 0x000f 087 060 030 Pre-fail Always - 9805559816
9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 10152
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 037 020 Old_age Always - 35
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 072 060 045 Old_age Always - 28 (Min/Max 24/30)
194 Temperature_Celsius 0x0022 028 040 000 Old_age Always - 28 (0 18 0 0)
195 Hardware_ECC_Recovered 0x001a 053 042 000 Old_age Always - 41270381
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 1SMART Error Log Version: 1
No Errors LoggedSMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Не слишком ли большие значения Hardware_ECC_Recovered? О чем это может говорить?
попробовал тест на скорость.
# dd if=/dev/ad0 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 58.482480 secs (17929746 bytes/sec)
~17Mb/sЭто при включенном nginx'е.
Далее отключаю нгинкс:
# nginx -s stopПробую снова:
# dd if=/dev/ad0 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 12.383725 secs (84673714 bytes/sec)
~80Mb/s# dd if=/dev/ad0 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 9.832123 secs (106647974 bytes/sec)
~100Mb/sВторой хард:
# dd if=/dev/ad2 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 9.685279 secs (108264923 bytes/sec)
~103Mb/s
iostat при тестах:
tty ad0 ad2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id
8 216 64.00 412 25.72 0.00 0 0.00 62 0 0 0 37
0 121 64.00 1652 103.25 0.00 0 0.00 62 0 1 1 36
0 113 64.00 1611 100.71 0.00 0 0.00 63 0 0 1 36
0 111 64.00 1637 102.32 0.00 0 0.00 54 0 1 1 45
0 317 62.74 1657 101.53 16.38 44 0.70 50 0 2 1 47
0 336 64.00 1607 100.46 0.00 0 0.00 50 0 1 1 48
0 90 64.00 1650 103.13 0.00 0 0.00 50 0 0 1 49
0 327 63.80 1626 101.32 9.00 6 0.05 50 0 1 0 49
0 329 64.00 1682 105.12 0.00 0 0.00 50 0 1 1 48
0 340 63.66 1664 103.44 16.00 12 0.19 50 0 1 1 48
72 397 5.14 7 0.03 5.14 7 0.03 50 0 0 0 50
12 361 0.00 0 0.00 64.00 474 29.63 50 0 0 0 50
0 121 0.00 0 0.00 64.00 1629 101.83 50 0 0 0 50
0 86 0.00 0 0.00 64.00 1670 104.37 50 0 0 0 50
0 325 6.67 3 0.02 63.90 1779 111.04 50 0 1 0 49
0 305 0.00 0 0.00 64.00 1757 109.84 50 0 1 0 49
0 210 0.00 0 0.00 64.00 1703 106.43 50 0 1 0 49
0 325 16.00 3 0.05 63.91 1623 101.31 50 0 1 0 49
0 353 2.00 1 0.00 63.96 1593 99.53 50 0 0 0 50
0 291 0.00 0 0.00 64.00 1600 100.03 50 0 1 0 49
0 113 0.00 0 0.00 64.00 1564 97.72 50 0 0 0 49
0 390 0.00 0 0.00 64.00 518 32.37 50 0 0 0 50
> Далее отключаю нгинкс:
> # nginx -s stopсмотрим nginx на предмет опции sendfile
и заодно показываем вывод:
kldstat -v | grep accf
и
nginx -V