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 поздно: про это я подумал, когда считалка уже сутки отработала. Да и не уверен, что виноват именно диск.

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

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

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

Трудно написать хорошее руководство по тому, что неизвестно по каким причинам возникает.

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

... и учитывая тот факт, что никаким 12309 тут и не пахнет — банальное «бутылочное горлышко», созданное неразумным использованием ограниченного ресурса — доступных диску iops'ов.

Кстати, при твоем алгоритме тебе не оператива нужна, а хороший SSD. Хотя, наверное, это один из тех примеров, когда хорошее железо решает проблевы плохого алгоритма

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

Ну так предложи другой вариант...

Писать в один файл записи фиксированного размера: координата пикселя — значение яркости. Тогда поиск любого пикселя в файле будет O(1) (смещение в файле напрямую вычисляется), поиск максимума — O(N), причем все в режиме *линейного* чтения.

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

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

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

По-хорошему, мне нужно было отказаться от cfitsio и использовать свою программку для чтения фитсов. Затем открыть все 150 файлов и поочередно считывать величины. Но лень же :)

Хотя так было бы правильно и намного быстрее.

А писать все в один файл - это же полная жесть будет!

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

Умная мысля приходит опосля... Можно было бы медианы сначала посчитать, сохранить их (количество файлов сильно поубавилось бы), а потом обрабатывать.

Но все равно пришлось бы свое писать: octave от такого померла бы точно (она у меня больше пяти несчастных изображений одновременно хранить в памяти отказывается - матюгается на нехватку памяти).

А 1 значение == 2 байта (uint16)

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

а что мешает задачу разбить на части? например, обрабатывать не всю матрицу 4K*4K, а, например, только одну строку? тогда результат точно в память поместится

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

Классический образ козла!

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