LINUX.ORG.RU

Частое обращение к диску приводит к жутким тормозам

 ,


0

1

У меня на рабочем компьютере запущена «считалка» в Octave. Считает она 3..4 суток (а потом - полученные данные надо будет еще с недельку обрабатывать). При этом промежуточные данные заносятся в файлы, их около 16млн. Каждую секунду открывается/закрывается около 1000 файлов. При этом компьютер почти что превратился в однозадачный: периодически зависает «вусмерть», не реагируя на клавиатуру и мышь в течение нескольких секунд; еще чаще - просто подтормаживает, зависая на секунду-другую.

Меры по борьбе с 12309 я проводил, добавил в /etc/sysctl.conf

vm.min_free_kbytes = 65536
vm.overcommit_memory = 2
vm.overcommit_ratio = 80
vm.dirty_bytes = 2097152
vm.dirty_background_bytes = 2097152
(предварительно занеся эти значения в соответствующие /proc/sys/...) Однако, тормоза от этого никуда не делись.

top показывает вот что:

Cpu0  :  7.4%us,  1.7%sy,  0.1%ni, 88.3%id,  2.2%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu1  :  2.5%us,  0.9%sy,  0.0%ni, 96.0%id,  0.6%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  2.4%us,  1.1%sy,  0.0%ni, 96.3%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  4.9%us,  0.8%sy,  0.0%ni, 94.2%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st

  814 eddy      20   0  776m 138m 1432 R   63  6.9   2753:26 octave

free:

Mem:       2064148    2005984      58164          0     222672     76226

Перекидывать структуру данных в /dev/shm поздно: про это я подумал, когда считалка уже сутки отработала. Да и не уверен, что виноват именно диск.

Вопрос: что можно сделать, чтобы система так не тормозила?

☆☆☆☆☆

чего-то ты недоговариваешь - у тебя больше 90% каждого проца свободно

anonymous
()
Ответ на: комментарий от anonymous

Все честно:

Cpu0  : 15.0%us, 28.9%sy,  1.0%ni,  0.3%id, 46.5%wa,  0.0%hi,  8.3%si,  0.0%st
Cpu1  :  0.3%us,  1.0%sy,  0.7%ni, 89.4%id,  8.6%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.3%us,  0.0%sy,  0.0%ni, 93.7%id,  5.9%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.7%sy,  0.0%ni, 92.7%id,  6.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2064148k total,  2010832k used,    53316k free,   296296k buffers
Swap:  4200992k total,   849864k used,  3351128k free,   743228k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                   
  814 eddy      20   0  776m 138m 1432 R   44  6.9   2778:10 octave                                                                                                    
18073 eddy      39  19 1045m 395m  17m S    2 19.6  47:01.11 firefox                                                                                                   
 5189 root      20   0 92008  30m 9396 S    1  1.5   2488:16 X  
Eddy_Em ☆☆☆☆☆
() автор топика

ну, не знаю как это в октаве реализовано, но видимо не в отдельных потоках, из-за этого имхо и тормоза.

aptyp ★★★★
()
Ответ на: комментарий от aptyp

Она вообще не параллелит вычисления: всего-то 1 ядро используется.

Но тормозит-то все жутко! несмотря на то, что октава грузит 1 ядро, да и то не полностью...

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от anonymous

Во-первых, других юзеров у меня нет.

Во-вторых, прибивать эту сессию иксов не могу.

В-третьих, заведение еще одной сессии иксов явно скажется в худшую сторону.

А тормозит все: периодически пропадает отклик на устройства ввода; подвисают окна; подвисает переключение рабочих столов (IceWM).

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

ну вот, из-за записи и тормозит, это же самая медленная часть.
жди, когда параллелить начнут, либо сам сделай.

aptyp ★★★★
()
Ответ на: комментарий от aptyp

Дык, ясен пень, я и сам мог сделать на сях распараллеливание - да лень… Тем более, что вычисления - одноразовые.

Кстати, насчет shm я погорячился: я же и использую сохранение на жесткий диск из-за того, что у меня оперативки слишком мало (у меня на компьютере 2ГБ, а надо хотя бы 256ГБ - но кто ж мне денег на это даст?)...

Eddy_Em ☆☆☆☆☆
() автор топика

Вопрос: что можно сделать, чтобы система так не тормозила?

Да ничего, скорее всего. TPS на дисковом контроллере - величина фиксированная. Для SATA дисков нормальных - где-то 300-400 транзакций в секунду.

(Потому люди на SSD и сваливают...)

sergv
()
Ответ на: комментарий от Eddy_Em

есть подозрение, что упирается все в юзерский лимит на количество одновременно открытых файлов; поделай вот так несколько раз:

$ ls -l /proc/814/fd/ | wc -l
посмотри что за дескрипторы (файлы, сокеты, пайпы,...) там открыты; проверь лимит ($ ulimit -a)

anonymous
()
Ответ на: комментарий от sergv

Для SATA дисков нормальных - где-то 300-400 транзакций в

секунду

Дык а почему же не имеющее отношения к диску притормаживает? Своп вроде бы не так уж и используется...

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Дык а почему же не имеющее отношения к диску притормаживает? Своп вроде бы не так уж и используется...

Firefox и его дисковый кэш? Или вообще все тормозит?

sergv
()
Ответ на: комментарий от anonymous

3 штуки /dev/pts/32, какой-то сокет, текущий файл и еще один файл постоянно открыт.

ulimit тоже в основном на inlimited (разве что кол-во файлов ограничено 1024 - я пробовал увеличить до ~16млн, но не получилось, поэтому и открываю файлы поочередно; ясное дело, если бы я их все одновременно открытыми держал, дело шло бы быстрее, т.к. сбрасывались бы буферы сразу по нескольку файлов, а не по-одиночке).

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от sergv

Похоже, неиспользуемые приложения уходят в своп, из-за чего сильно тормозят при попытке их активации. А вот огнелис и thunderbird вроде в свопе не сидят (т.к. сильно не тормозят), но при наборе текста периодически возникает зависание.

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

А на ЛОРе флудить?

я за тебя пофлужу :)

anonymous
()

О, du отработал: вспомогательных данных уже на 65ГБ. В бинарном виде было бы ~30ГБ. Но это - только половина.

Так что, мне бы и 64ГБ оперативки хватило.

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

И как я буду на письма отвечать? А на ЛОРе флудить?

ну, временно же;
к тому же, перезапустить лису - в любом случае польза будет, и потом не открывать много вкладок;
также посмотри какие приложения еще память жрут: в top'е нажми 'M'

anonymous
()
Ответ на: комментарий от Eddy_Em

mutt и luakit наверное временно тебя в этом плане могут спасти

gnunixon ★★★
()
Ответ на: комментарий от unanimous
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  1 655940  51732 235896 1015356    1    0     0     0    1    0  4  1 94  1
 1  0 655940  47580 235508 1020824    0    0 10184  8356 3238 8227  6  9 75 11
 1  1 655940  48672 235684 1018956    0    0  7888  8276 2695 6626  7  6 75 13
 0  1 655940  52312 235516 1014380    4    0 10452  8328 3348 8281  9 11 66 15
 0  1 655940  50100 234316 1018376    4    0 10640 12532 3472 8830  8 12 71  9
 1  1 655940  52456 234444 1014144    0    0 11344 10524 3745 9435  7 13 73  7
 1  0 655940  51360 234920 1017804    0    0  7352  8864 2598 6214  3 10 69 19
 1  0 655940  48176 235208 1022332    0    0 10904  8436 3758 9504 10 12 71  7
 1  1 655940  51244 235468 1021712    0    0 11068 12392 3484 8918  7 11 74  8
 1  0 655940  53372 235812 1018028    0    0 12004 12460 3922 9965  9 12 74  6
 1  0 655940  52616 236052 1018524    0    0  9388  8360 2802 6635  7  6 70 17
 1  0 655936  48572 236204 1022196   32    0  5804  4156 1859 4189  3  6 67 25
 1  1 655936  50316 237508 1019140    0    0  7956  6256 2939 7175  6  8 72 14
 1  0 655936  50420 237572 1021212    0    0 10392 12976 3285 8390  6 11 75  9
Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от unanimous

Вообще, конечно, непрерывный ввод И вывод, скоростью 10 Mb/c вызывает определенные тормоза... Сделай еще ionice -c3 -p PID_считающего_процесса и отрапортуй, стало ли легче.

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

Сделал, тормозит все равно.

Сделай еще ionice -c3 -p PID_считающего_процесса

так оно же у меня тогда считать вообще месяц будет!

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

так оно же у меня тогда считать вообще месяц будет!

это из каких соображений ты сделал столь потрясающий вывод?

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

Ну так если затормозить обращения к диску, то и весь процесс затормозится.

А вообще, ладно: если эти тормоза связаны только с тем, что у меня на компьютере слишком мало оперативки, а работа со свопом тормозится из-за того, что octave постоянно дергает диск, переживу.

Я-то думал, что тормоза могут быть связаны с чем-то еще. Вот уж не думал, не гадал, что мне может стать мало 2ГБ оперативки...

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Ну так если затормозить обращения к диску, то и весь процесс затормозится.

Как эта команда *тормозит* обращения к диску? она всего лишь говорит, что твой процесс будет обслуживаться по остаточному принципу, что, учитывая тот факт, что 99% времени компьютер (и диск) все равно ничего не делают примерно и даст оценку замедления. Надеюсь, у тебя хватает ума не качать торренты по гигабиту во время расчетов.

если эти тормоза связаны только с тем, что у меня на компьютере слишком мало оперативки

Ты постоянно высказываешь ложные предположения, как ты вообще в науке работаешь? При чем тут оперативка, если происходит постоянный ввод/вывод и кэш помогает мало — данные постоянно вытесняются из него ввиду характера нагрузки? Он бы помог, конечно, если бы *все* данные лезли в него, а это, много десятков гигабайт — т.е. совершенно нереальные цифры для настолького компа.

unanimous ★★★★★
()
Ответ на: комментарий от Eddy_Em

И вообще, я смотрю, ты никуда не спешишь, поскольку если бы спешил, давно переписал бы все на C++/fortran. Считать в матлабе что-то, требующее >получаса расчетов — форменное извращение. Матлаб — он для прототипирования и отладки, ни для чего более.

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

Дык, все равно узкое место здесь - дисковые операции. Ну не могу я одновременно >16млн файлов открытыми держать!

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от unanimous

Надеюсь, у тебя хватает ума не качать торренты по гигабиту во время расчетов.

У меня поднят ftp- и http-сервер. Который, хоть и не сильно, но нагружается периодически.

При чем тут оперативка, если происходит постоянный ввод/вывод и кэш помогает мало — данные постоянно вытесняются из него ввиду характера нагрузки?

При том, что данные, туда не влезающие, лезут в своп. А иначе с чего бы тормоза были?

много десятков гигабайт — т.е. совершенно нереальные цифры для настолького компа.

Пока, к сожалению, да. Хоть оперативка и недорогая нынче, ее надо во что-то втыкать. И это что-то стоит намного дороже...

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Ну не могу я одновременно >16млн файлов открытыми держать!

Я не знаю, что ты там делаешь, но, возможно, что-то ты делаешь неправильно. Возможно, проще было бы писать в один файл, разделяя записи тегами, а потом просто его рассплитить по этим тегам — это потоковая операция, на которых современные винты выдают >100 Mb/c, т.е. сам сплит займет относительно малое время.

unanimous ★★★★★
()
Ответ на: комментарий от Eddy_Em

У меня поднят ftp- и http-сервер.

Что ты споришь, я не понимаю? Возьми и попробуй — оценишь, насколько замедляется. Не думаю, что в разы, скорее, на проценты.

unanimous ★★★★★
()
Ответ на: комментарий от Eddy_Em

При том, что данные, туда не влезающие, лезут в своп.

А за это скажи «спасибо» ненулевому swappiness. Сейчас должно быть все ОК.

unanimous ★★★★★
()
Ответ на: комментарий от unanimous

Я хочу построить попиксельную статистику для светоприемника 4Кх4К. Для этого я поочередно открываю ряд изображений, полученных с экспозицией N секунд, медианой их усредняю и пишу уровень сигнала в каждом пикселе в отдельный файл. Затем я поочередно буду обрабатывать эти файлы, дабы построить маску битых пикселей, горячих пикселей и коэффициента линейности.

В один файл это писать не получится - как его потом обрабатывать, этот 60-гигабайтный файл?!

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от unanimous

Сделал: скорость упала на ~13%. Но диск тарахтеть реже стал.

А за это скажи «спасибо» ненулевому swappiness.

А в руководстве по борьбе с 12309 было сказано сделать его ненулевым...

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Dark_SavanT

Без понятия.

Кстати, unanimous, спасибо за ionice: тормоза пропали (правда, с ущербом вычислениям, но как пойду на ужин, верну все взад).

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

пишу уровень сигнала в каждом пикселе в отдельный файл.

Пипец! Ты в курсе, что оверхед такого подхода over9000? Фактически, это худшее, что можно придумать: время записи нескольких байтов несравнимо меньше времени, затрачиваемого системой на поиск свободного блока, апдейта дерева ФС, запись журнала и сброса буфера на диск?

unanimous ★★★★★
()
Ответ на: комментарий от Eddy_Em

но как пойду на ужин, верну все взад

В этом нет смысла: как только то отойдешь от компа, «посторонний» ввод-вывод практически сойдет на нет (не считая, конечно, всяких втп и веб-серверов)

unanimous ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.