форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Файловые системы, диски)
Изначальное сообщение		[ Отслеживать ]

"Помогите определить, тормозят ли диски?"	+/–
Сообщение от makarov (??) on 23-Янв-11, 00:58
Всем привет. Стоит на сервере 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 Free   PID 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". но ведь пара регулярок в конфиге нгинкса не могут быть причиной этих проблем? Всем заранее спасибо за ответы!
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Помогите определить, тормозят ли диски?"	+1 +/–
Сообщение от Aquarius (ok) on 23-Янв-11, 02:18
да, искать узкое место следует P.S. а памяти сколько и какие файловые системы в ходу?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от makarov (??) on 23-Янв-11, 09:44
	> да, искать узкое место следует > P.S. а памяти сколько и какие файловые системы в ходу? Памяти - 8ГБ, ФС используется ufs.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Помогите определить, тормозят ли диски?"	+1 +/–
Сообщение от sherlock (ok) on 23-Янв-11, 07:30
> Так вот хочется понять, нормальная ли это ситуация или здесь явно проблема > и следует ли искать узкое место? Ну вообще-то 100% загрузки диска, это говорит не о том, что он тормозит по какой-то причине, а о том, что он пашет как папа карло и не справляется с нагрузкой. Модернизируйте дисковую подсистему, либо берите приличный дисковый контроллер с массивом, ну либо бюджетный вариант, вместо 2 х 1TB - Raid1, сделайте например 4 х 500MB - Raid10 ( GMirror попарно + GStripe) либо еще меньше 8x250, чтобы увеличить кол-во работающих винтов, при сохранении результирующего объема, тогда нагрузка будет сильнее размазываться по ним, а не концентрироваться на двух. 2. У Вас вся нагрузка на FS mirror/gm0s1f, подозреваю, что там и база мускля и сами данные веба, неплохо бы разнести, да и вообще систему надо поставить отдельно, а не на винты с данными.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от makarov321 (ok) on 23-Янв-11, 09:47
	>[оверквотинг удален] > тормозит по какой-то причине, а о том, что он пашет как > папа карло и не справляется с нагрузкой. Модернизируйте дисковую подсистему, либо > берите приличный дисковый контроллер с массивом, ну либо бюджетный вариант, вместо > 2 х 1TB - Raid1, сделайте например 4 х 500MB - > Raid10 ( GMirror попарно + GStripe) либо еще меньше 8x250, чтобы > увеличить кол-во работающих винтов, при сохранении результирующего объема, тогда нагрузка > будет сильнее размазываться по ним, а не концентрироваться на двух. > 2. У Вас вся нагрузка на FS mirror/gm0s1f, подозреваю, что там и > база мускля и сами данные веба, неплохо бы разнести, да и > вообще систему надо поставить отдельно, а не на винты с данными. 1. варианта железной модернизации пока что нет. 2. на gm0s1f как раз находится статика, т.е. папка с фотографиями. отключаю выдача фото в нгинксе -- сразу падает нагрузка этого раздела практически до нуля.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	20. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 24-Янв-11, 10:09
	> 1. варианта железной модернизации пока что нет. Если так, то я бы пробовал: 1. использовать 'load' balancing mode для gmirror. После r200286 для RELENG7 этот метод баллансировки отслеживает положение головок при выборе диска, что позволяет снизить временнЫе затраты на перепозиционировании. Т.е. load должен показать результаты лучше, чем round-robin. Для этой вкусности придётся обновиться хотябы до 7.3. 2. задействовать AHCI (что потребует перехода как минимум на RELENG8, со всеми вытекающими неудобствами обновления) И два вопроса: - в первом выводе gstat у вас 300 операций записи в секунду. Кто источник этих операций? - файловые системы смонтированы с ключиком noatime?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	26. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от makarov321 (ok) on 24-Янв-11, 20:07
	>[оверквотинг удален] > 1. использовать 'load' balancing mode для gmirror. После r200286 для RELENG7 этот > метод баллансировки отслеживает положение головок при выборе диска, что позволяет снизить > временнЫе затраты на перепозиционировании. Т.е. load должен показать результаты лучше, > чем round-robin. Для этой вкусности придётся обновиться хотябы до 7.3. > 2. задействовать AHCI (что потребует перехода как минимум на RELENG8, со всеми > вытекающими неудобствами обновления) > И два вопроса: > - в первом выводе gstat у вас 300 операций записи в секунду. > Кто источник этих операций? > - файловые системы смонтированы с ключиком noatime? 1. а как узнать, кто источник операций? или только через top? 2. нет, не смонтированы. существенный прирост дает?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	31. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 25-Янв-11, 00:15
	> 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 (как минимум те, что под высокой нагрузкой).
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

5. "Помогите определить, тормозят ли диски?"	+/–
Сообщение от PavelR (??) on 23-Янв-11, 10:13
> в 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гб, туда нгинкс записывет горячую статику, каждые полчаса >диск подчищается. ПОДчищается или полностью зануляется?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 23-Янв-11, 11:32
	> Исходя из собственного понимания мира, могу предположить что оперативка системы не используется > для файлового кеширования. Да и в данный момент 2152M Inact.... Печально > :-) Вы не правы. Inact в данном случае какраз показывает объём данных находящихся в дисковом кэше.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от PavelR (??) on 23-Янв-11, 13:48
	>> Исходя из собственного понимания мира, могу предположить что оперативка системы не используется >> для файлового кеширования. Да и в данный момент 2152M Inact.... Печально >> :-) > Вы не правы. Inact в данном случае какраз показывает объём данных находящихся > в дисковом кэше. Ткните меня, пожалуйста, в соответствующую документацию.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 23-Янв-11, 22:19
	> Ткните меня, пожалуйста, в соответствующую документацию. Документацию на взлёт не подскажу, но приведённый ниже пример подтверждает мои слова. 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#
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	15. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от PavelR (??) on 24-Янв-11, 07:48
	>[оверквотинг удален] > 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# > Угум, хороший пример, спасибо.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от PavelR (??) on 24-Янв-11, 07:49
	>[оверквотинг удален] > 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 или что там...) - тюненые ?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 24-Янв-11, 09:23
	> а там это, всякие специфические опции в loader.conf (KVA или что там...) > - тюненые ? Ядро собрано с KVA_PAGES=512, и в loader.conf есть vm.kmem_size_max="1400M". Оба параментра влияют на адресное пространство ядра и в моём понимании не будут влиять на работу дискового кэша. Если хотите - могу повторить опыт убрав эти параметры.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	19. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от PavelR (??) on 24-Янв-11, 10:02
	>> а там это, всякие специфические опции в loader.conf (KVA или что там...) >> - тюненые ? > Ядро собрано с KVA_PAGES=512, и в loader.conf есть vm.kmem_size_max="1400M". Оба параментра > влияют на адресное пространство ядра и в моём понимании не будут > влиять на работу дискового кэша. Если хотите - могу повторить опыт > убрав эти параметры. А на что они тогда влияют? Повторить опыт - если не сложно - было бы интересно, просто у меня нет быстрой возможности его провести. Спасибо за "ликбез" :-)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	22. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 24-Янв-11, 11:01
	> Повторить опыт - если не сложно - было бы интересно, просто у > меня нет быстрой возможности его провести. Результат без дополнительных параметров в ядре и 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
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	21. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от PavelR (??) on 24-Янв-11, 10:36
	>> а там это, всякие специфические опции в loader.conf (KVA или что там...) >> - тюненые ? > Ядро собрано с KVA_PAGES=512, и в loader.conf есть vm.kmem_size_max="1400M". Оба параментра > влияют на адресное пространство ядра и в моём понимании не будут > влиять на работу дискового кэша. Если хотите - могу повторить опыт > убрав эти параметры. Ну и если Inact - это файловый кеш, не возникает ли в случае топикстартера двойного использования оперативки (двойного хранения файла в RAM) в случае использования "диска-в-памяти" md ?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 24-Янв-11, 11:12
	> Ну и если Inact - это файловый кеш, не возникает ли в > случае топикстартера двойного использования оперативки (двойного хранения файла в RAM) > в случае использования "диска-в-памяти" md ? Я тоже подумал про double caching при работе с md, но автор трида упоминал, что "Без (memory) диска ситуация еще хуже, в gstat'e почти всегда 100%" Единственное объяснение, приходящее в голову это при отключении md автор либо не дождался хоть какого-то наполнения дискового кэша, либо горячая статика нгинкса продолжала записываться на hdd, создавая дополнительную нагрузку. Или как вариант - md не был удалён и память не была возвращена "в систему". makarov, вы не моглибы подтвердить/опровергнуть приведённые выше предположения?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	24. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от MiF (ok) on 24-Янв-11, 11:23
	> Единственное объяснение, приходящее в голову это при отключении md автор либо не > дождался хоть какого-то наполнения дискового кэша, либо горячая статика нгинкса продолжала > записываться на hdd, создавая дополнительную нагрузку. Или как вариант - md > не был удалён и память не была возвращена "в систему". Да хоть 10 раз пусть кэшируется. У человека скорость меньше 10мб/с, без кэша вообще диски больше выдадут. Не такая у него и большая нагрузка, по top'у очевидно что памяти хватает. У него при 100% занятости диска идет 7 мег. в секунду, диск банально перечитывает сектора по несколько раз, так как от вибрации не может удержать головку у нужном месте.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 24-Янв-11, 11:46
	> Да хоть 10 раз пусть кэшируется. У человека скорость меньше 10мб/с, без > кэша вообще диски больше выдадут. Не такая у него и большая > нагрузка, по top'у очевидно что памяти хватает. У него при 100% > занятости диска идет 7 мег. в секунду, диск банально перечитывает сектора > по несколько раз, так как от вибрации не может удержать головку > у нужном месте. Если бы при линейном чтении скорость была 7 мег. в секунду, то да - это была бы проблема и я бы согласился с тем, что "диск банально перечитывает сектора по несколько раз". А в данном случае речь идёт про random i/o (из-за высокого количества параллельных запросов к зеркалу + round-robin при выборе hdd в зеркале + отсутствия ncq). Время позиционирования при ходе головки на "quarter stroke и более" будет составлять 10-30ms, так что при трёхстах операциях в секунду львинная доля времени будет потрачена на seek time.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	27. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от makarov321 (ok) on 24-Янв-11, 20:12
	>[оверквотинг удален] >> случае топикстартера двойного использования оперативки (двойного хранения файла в 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
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	32. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 25-Янв-11, 00:23
	> и ситуация сейчас такая: > Mem: 721M Active, 2238M Inact, 734M Wired, 195M Cache, 399M Buf, 4001M > Free если через несколько часов мы не увидим переползания Free в Inactive, то я бы хотел посмотреть на вывод команды sysctl -a | grep vnodes
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	33. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от makarov321 (ok) on 25-Янв-11, 12:13
	>> и ситуация сейчас такая: >> 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
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	34. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от temny (ok) on 25-Янв-11, 16:14
	> переползание видимо произошло да - в этом плане всё хорошо - почти 6Гб в дисковом кэше
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

8. "Помогите определить, тормозят ли диски?"	+/–
Сообщение от mef (ok) on 23-Янв-11, 15:30
Может Вам попробовать ZFS + тюнинг? Только систему надо бы обновить. Если с финансовыми ресурсами напряженка, то можно попробовать оба диска не полностью превращать в mirror. Сделать, например, три пула: один mirror, и по одному пулу на оставшихся частях дисков. И пробовать не важные файлы, но критические по скорости, размазать по эти двум пулам.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Помогите определить, тормозят ли диски?"	+/–
Сообщение от MiF (ok) on 23-Янв-11, 16:36
Если я правильно посчитал столбцы, то у вас очень медленная скорость работы диска? так? Причем настолько, что тюнинг, fs и т.д. не играю тут никакой роли. Сервер в стойке? Кулера уже жужжат небось, а винты десктопные? Предполагаю вибрацию и как следствие падение скорости. Решение замена винтов на серверные с защитой от вибрации. Если бюджет не позволяет, то если винты не в корзинках, проложите под болты проставки силиконовые или еще че.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от makarov321 (ok) on 23-Янв-11, 17:05
	> Если я правильно посчитал столбцы, то у вас очень медленная скорость работы > диска? так? Причем настолько, что тюнинг, fs и т.д. не играю > тут никакой роли. > Сервер в стойке? Кулера уже жужжат небось, а винты десктопные? Предполагаю вибрацию > и как следствие падение скорости. Решение замена винтов на серверные с > защитой от вибрации. Если бюджет не позволяет, то если винты не > в корзинках, проложите под болты проставки силиконовые или еще че. платформа: http://www.nix.ru/include/view-photo.html?good_id=98912&pid=... винты: http://www.nix.ru/autocatalog/hdd_seagate/HDD_Tb_SATAII_Seag... а какие варианты оптимальных винтов можете посоветовать?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от MiF (ok) on 23-Янв-11, 17:42
	С вибрацией хорошо справляются WD RE3 (RE4 хуже, лучше взять RE3). Винты у вас очень плохие, юзал штук 50 таких половина умерла в первые 4 месяца (хотя там помойму серия была с ошибкой в прошивке). Вибрацию они вообще не держат. Если у вас есть возможность потушить сервер ненадолго, снимите винты и попробуйте их включить держа в руках например, чтобы вибрация не передавалась. Скорость должна выправиться.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	13. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от emfs (ok) on 23-Янв-11, 18:41
	http://www.nix.ru/autocatalog/hdd_western_digital/HDD_Tb_SAT... А вот такие подойдут в такой ситуации?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от MiF (ok) on 24-Янв-11, 08:25
	> http://www.nix.ru/autocatalog/hdd_western_digital/HDD_Tb_SAT... > А вот такие подойдут в такой ситуации? Лотерея с маленькой вероятностью на успех. Или RE3 серия WD или ES от сегейта (но я с сегейтом стараюсь не связываться, уж очень часто нарывался на бракованные партии, то прошивка, то еще че, а уж декстопные винты их летят просто пачками :(). По мне так вам нужно: 1. включить сервер с винтами в ситуации когда на них не передается вибрация. убедиться с помощью dd например что запись на них идет в приемлемой скоростью подтвердив тем самым, что проблема в этом. 1.1. если проблема не решится загрузиться с флешки или livecd (френзи или что сейчас модно, давно BSD юзать не приходилось). Это возможно подтвердит, что проблема в настройках системы. 2. купить RE3 несмотря на цену (проверить старые винты на ошибки и спихнуть кому-нить в десктоп). вы платите за надежность. и десктопные диски могут замечательно годами работать в сервере, но вероятность этого не велика (обычно они даже быстрее серверных работают, но если условия позволяют). p.s. и еще раз повторю, я могу ошибаться, поэтому проверку считаю необходимо провести.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	28. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от makarov321 (ok) on 24-Янв-11, 20:13
	MiF, спасибо за сообщения, очень интересные мысли по поводу вибраций. Сегодня потушу нгинкс и попробую погонять на скорость записи/чтения. Чуть позже отпишу нижу по результатам тестов. Харды заменить готов без проблем, только в этом ли проблема..
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	12. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от YuSt on 23-Янв-11, 18:36
	> винты: http://www.nix.ru/autocatalog/hdd_seagate/HDD_Tb_SATAII_Seag... ... мдя... с этого и нужно было начинать. Тушите сервак, вытягиваете оттуда этих уродцев и в торжественной обстановке дарите их тому, кто принял решение о покупке... Присоединяюсь к выше написанному - наплачитесь Вы с ними ...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

29. "Помогите определить, тормозят ли диски?"	+/–
Сообщение от makarov321 (ok) on 24-Янв-11, 20:16
еще некоторая информация, которая может оказаться полезной. 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: PASSED General 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       -       0 SMART Error Log Version: 1 No Errors Logged SMART 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: PASSED General 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       -                 1 SMART Error Log Version: 1 No Errors Logged SMART 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? О чем это может говорить?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Помогите определить, тормозят ли диски?"	+/–
Сообщение от makarov321 (ok) on 24-Янв-11, 23:05
попробовал тест на скорость. # 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Помогите определить, тормозят ли диски?"	+/–
	Сообщение от universite (ok) on 01-Фев-11, 00:55
	> Далее отключаю нгинкс: > # nginx -s stop смотрим nginx на предмет опции sendfile и заодно показываем вывод: kldstat -v | grep accf и nginx -V
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема