i/o снизить нагрузку.

Похоже что-то подобное есть. # ionice -c3 -p89 , где 89 это pid процесса. Я могу из cron тогда запускать некий сценарий, который будет находить мне все PID бинарных файлов rm и понижать им приоритет? zm запускает вроде несколько копий rm с различными параметрами.

Можно как-то сделать так, чтобы бинарный файл rm, ВСЕГДА имел низкий ionice?

Запускать родителя с ionice -c3 :)

То есть в top скачет нечто: rm

Лучше же по iotop следить.

Это можно организовать, но вот вопрос, а как tmpfs поймёт куда скидывать данные в реале?

Никак, перекидывать на диск надо скриптом запускаемым по крону.

Я могу из cron тогда запускать некий сценарий, который будет находить мне все PID бинарных файлов rm и понижать им приоритет?

Можно, но не эффективно. В среднем, каждый rm по половине минуты будет крутиться с нормальным ionice, пока ежеминутный cron его поймает. Хотя, конечно, можно чаще в духе:

#!/bin/bash

/usr/local/bin/renicer.sh

bash -c 'sleep 15; /usr/local/bin/renicer.sh' &
bash -c 'sleep 30; /usr/local/bin/renicer.sh' &
bash -c 'sleep 45; /usr/local/bin/renicer.sh' &

Тогда раз в 15 секунд будет ренайситься.

У тс проблема не в кешировании. А в удалении старого материала.

а ты подумай ПОЧЕМУ эта странная проблема возникает

В scripts/ZoneMinder/lib/ZoneMinder/General.pm есть deleteEventFiles. Я бы на твоем месте просто подредактировал вызовы rm.

Я пока не совсем хорошо понимаю, как мне использовать ОЗУ в качестве кеша... :(
sudo mount -o size=3G -t tmpfs none /mnt/

ради теста посмотрите на скорость работы такой ФС

а ты подумай ПОЧЕМУ эта странная проблема возникает

Гг. То же мне Роден нашелся. Проблема возникает потому что у чистилки такой же приоритет как и у писалки. Но предлагай пить боржоми и дальше, ок.

Ооо... Вот такое нашёл! Следовательно, могу накрутить прямо туда ionice.

my $command = "/bin/rm -rf ".$event_path;

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

Да скорость записи мне то всё равно, мне необходимо чтобы у меня было меньше ввода/вывода. При том, у меня беда в том, что приоритет процессов записи, и приоритет процесса удаления - одинаков.

они пишутся в несколько потоков, а после падения питания от низкого бюджета, фс без журнала захочет почекаться

Но предлагай пить боржоми и дальше, ок.

ionice уже предлагали
а ты что предложил кроме простого повторения? у меня хоть боржоми работает

оставь cfq и в команде удаления зонемаиндером старого хлама припиши ionice -c3

Это полное Г. Так-как мне придётся не перекидывать в момент отработки rm -rf то есть нужно будет как-то отслеживать когда оно там закончится. Можно, но костыльно.

Я предложил подправить конкретное место в коде)))

у меня хоть боржоми работает

Нет, его надо сначала реализовать.

Я думаю, что предложение более чем дельное! Именно это мне и нужно было. Главное, чтобы теперь rm -rf вообще завершался, а то я ему накрутил: -c3. Ну будем посмотреть. :)

По хорошему надо избавляться либо от кучи мелких файлов в архиве, либо от HDD. Ворочать кучу мелких файлов это в принципе не быстро, а на харде тем более.

Я предложил подправить конкретное место в коде)))

ну, если оно работает, но отличное решение, я же ничего не имею против =)
хотя, как по мне, ionice не всегда работает корректно
уже недавно была тема, тоже были вопросы о доступе к HDD, ionice не давал эффекта

Нет, его надо сначала реализовать.

его надо сначала проверить
А проверить можно в течении 10 минут максимум
Реализовать рабочее решение - максимум час

А проверить можно в течении 10 минут максимум
Реализовать рабочее решение - максимум час

С дивана оно конечно виднее. Вот поэтому оценки разработчиков и умножаются на много-много, чтобы хоть как-то реальность приблизить.

С дивана оно конечно виднее.

с твоего дивана?
я с ramdisk-ом работал достаточно много времени, и посоветовал его не просто так

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

они умножаются по разным причинам

с твоего дивана?

С моего старого дивана, с твоего нового ни черта не видать, ага.

они умножаются по разным причинам

Основная — витание в абстрактных облаках и невнимание к деталям. Я бы с удовольствием посмотрел как ты пыжешься за 10 минут проверить кеш, максимум, гг.

Ой... А мне читать тоже же надо (зайти через web, посмотреть старые записи). Это никуда не годное решение, у меня аппликация свалится.

невнимание к деталям

Вниманием к деталям, сейчас может похвастаться буквально один на миллион наверно... - Я к примеру весьма рад, что Вы внимательно прочитали мой тред. Пока не могу сказать насколько всё будет хорошо, или плохо. Но вполне возможно, что Вы мне сэкономили множество времени, денег, и уберегли от костылей. :)

и уберегли от костылей

какой Вова молодец, от костылей уберег

а сам-то вместо кучи jpeg-ов мог в tarpipe писать, он уж не жрет процессор

Не очень понимаю об чём это? Я пишу jpg, потому что так пишет zoneminder. Это не моя наколенная поделка. Это довольно сложный продукт. И куда-то в него лезть чтобы там писать тарпайпом или прочими вещами - нет смысла. У меня один поток jpeg пишется со скоростью: 512 кб/сек. Таких процессов у меня по числу камер. И того, пока примерно: 15 мегабайт/сек. Какой нафиг tarpipe... Процесс сказал положить jpeg, а куда его положит файловая система, это уже только она и знает. Современная файловая система по максимуму избегает дефрагментации, и запросы на запись ОС - по-возможности объеденяет в большие блоки. - Так что я думаю, мне что 23 tarpipe, что просто 23 процесса jpeg писать - погоды не сделает.

Да и вообще, какой нафиг tarpipe, если у меня пользователь может посмотреть НЕДЕЛЬНОЕ событие с любой камеры проведя мышкой по timeline?

И так!

Результаты следующие: Во-первых мне тут подсказали использовать iotop. За что отдельное спасибо.

В общем теперь процессы rm -rf стали жить в режиме: idle. la по-прежнему высок. Но теперь войти на сервер по ssh можно со второго раза. В общем, субъективно, стало жить полегче немного. Но...

Вот чего говорит iotop: в те моменты, когда отрабаывает rm -rf, он говорит нечеловеческим голосом, что забивают всё на свете процессы: kworker (их много) и процесс: jbd2/sda3-8 - тот, так вообще тащится то того чем он занимается...

jbd2 - это журнал насколько я понял. А вот про kworker - не очень понятно. Но они убираются, когда убирается активный rm -rf. Думаю это служебные процессы ядра.

В спокойном состоянии, jbd2 кушает: 8-50 % i/o, судя по iotop.

Что делать? Можно-ли журнал перенести на SSD? Или выбрать другую ФС - для множества мелких файлов (512-1 мб)?

P.S. find / -name reprimand MrClon

Может вынести: /var/www/zm - в отдельную фс, с опцией:

* writeback mode In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.

В смысле, сразу запускается несколько rm? Тогда это упячка.

А вот кстати не смотрел, столько их там одновременно rm -rf ов то. Ну мне в целом я думаю поможет положить журнал на отдельную SSD партицию?

Просто купи еще 1 диск и пусть часть камер пишет туда

Заменяешь rm на bash-обертку которая его всегда запускает с ionice -c 3 и не надо никаких кронов.

Ну мне в целом я думаю поможет положить журнал на отдельную SSD партицию?

Может тогда уже просто журнал отключить? А так остаются только костыли, например написать свою чистилку или готовить суточные разделы на фс, которые потом можно целиком грохать.

Средствами zoneminder это сделать не возможно. Он предпочитает писать в один раздел.

Мне сейчас не хватает 4ТБ (чисто по времени хранения архивов, получается на каждую камеру 7 дней, а с учётом планируемого роста камер, мне надо бы подумать о расширении), стало быть: я сделаю RAID 0, из двух дисков, например таких: H3IK40003272SE. На SB60GB-IGNT-25SAT3 поставить ОС + расположить журнал от RAID 0.

Как-то так. По деньгам дисковая подсистема мне обойдётся в: 1550 + 6 550 + 6 550 = 14650. Не дёшего...

Можно поступить и иначе: оставить тот диск что там уже есть, докупить к нему: DT01ACA300 , и ASP600S3-32GM-C. Тогда выйдет: 1440 + 4300 = 5740. - Что уже значительно дешевле.

Может тогда уже просто журнал отключить?

Не вижу больших препятствий к этому. Но в крайнем случае при пропадании питания, чем мне это может угрожать? Полный кирпич и мусор из всей файловой системы?

Полный кирпич и мусор из всей файловой системы?

Да нет, на ext2 люди вполне себе и без БП жили.

Эм... Что будет то? У меня ФС будет неделю чекаться? :) Часть файлов оно не сможет восстановить. Это понятно. Это ок. Но вот то, что оно неделю будет там чекаться - это уже не хорошо...

Тебе поможет:

- RAID0, а лучше 10, данные всё-таки
- SSD если им заменить диск. SSD-кеш(dm-cache) тебе поможет вряд ли, он для «горячих» данных, а у тебя линейное чтение/запись
- запускать такие операции с соответствубщим ionice
- ещё можно попробовать для ext4 вынести journal на отдельное устройство(лучше на SSD)

- ещё можно попробовать для ext4 вынести journal на отдельное устройство(лучше на SSD)

А это можно делать для / ?

Если ionice для rm -rf не работает, можешь попробовать сделать паузы вручную. Вместо rm -rf запускай свой скрипт, который будет удалять файлы по одному и немного спать между удалениями. хз получится или нет но теоретически должно помочь

Если у тебя нет бп, то его в любом случае надо приобрести.

БП будет. Но мало-ли чего... Всё же, если у меня файловая система будет чекаться месяц - это как-то не очень...

Если ionice для rm -rf не работает, можешь попробовать сделать паузы вручную.

Да оно то в целом работает. Оно там пошуршит, пошуршит... - Всё бы ничего, но для журнала ionice я думаю уже не выставить, а у меня именно журнал бушует. Паузы вручную - не получится сделать точно, там rm -rf по динамической маске.

Всё же, если у меня файловая система будет чекаться месяц - это как-то не очень...

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

Для тебя сейчас самые дешевые варианты отключить журнал или вынести его на SSD.

Лично мне бы было легче написать свой zmaudit. Тут уж каждый сам выбирает.

Лично мне бы было легче написать свой zmaudit.

Идеально конечно было бы. Но я не асилю. :(

Для тебя сейчас самые дешевые варианты отключить журнал или вынести его на SSD.

Я думаю на SSD его унести. :)

Хз, не уверен. А хачем хранить данные сервисов в / ?

Поставь от себя в крон rm файлов старше определенной даты на ночь (или когда там нагрузка меньше) и тереться будут быстрее и zm в рабочее время не так систему напрягать будет.

Средствами zoneminder это сделать не возможно. Он предпочитает писать в один раздел.

Смонтировать другой винт в /mnt/sdb1 например, далее:
mount /mnt/sdb1/2 /var/cache/zoneminder/events/2 -o bind
mount /mnt/sdb1/7 /var/cache/zoneminder/events/7 -o bind
...
где 2, 7 - это номер камеры.

Можно ещё собрать 2-ой комп и разнести камеры.