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

У тебя идёт постоянная линейная запись? Не думаю что буферизация записи тут поможет. Хотя может помочь если запись идёт в несколько потоков.

В принципе просто замена диска на другой, с большей скоростью вращения, уже должна ускорить запись, вопрос на сколько.

Думаю RAID0, в твоём случае, может не дать результата. Есть не нулевой шанс что все потоки записи (или большинство их) придутся на один диск.

la, прыгает до 13

ОГО! LA Тринадцать! Вот это ж нифига себе!

cgroups?

У тебя идёт постоянная линейная запись?

А второй вывод команды не отвечает на этот вопрос? Не думаю что линейная. У меня 23 потока mjpg. Думаю оно там весьма рандомное...

LA 13 - не много. Однако, я боюсь потерять кадры, это во-первых, а во вторых, у меня из-за столь высокой утилизации диска, 98-99 процентов - фактически, на сервер, нельзя войти даже по ssh. Не говоря уже про web.

А чем это мне может помочь? Пока не очень уверен... Можно настроить на исполнение бинарного файла rm свой cgroups?

Думаю RAID0, в твоём случае, может не дать результата. Есть не нулевой шанс что все потоки записи (или большинство их) придутся на один диск.

Вот и я тоже не знаю, по сему пришёл сюда. :)

Хотя может помочь если запись идёт в несколько потоков.

23 процесса постоянно пишут на диск. Ну и служебные просыпаются периодически.

проще и дешевле докупить ОЗУ, и начать работать с ramdisk
а потом уже пакетно синхронизировать с hdd

Так-так... - ОЗУ на сервере есть как минимум 3-5 гб. свободной (судя по выводу htop). Что я могу в этом свете предпринять без переразметки диска? Просто у меня ощущение, что это мне не поможет всё же... Ядро то всё же лучше знает чего и как взять под кеши.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       3,6T  3,3T  290G  93% /

# free -m
             total       used       free     shared    buffers     cached
Mem:          7864       7319        545       1231       1186       3289
-/+ buffers/cache:       2843       5021
Swap:            0          0          0

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

Ядро мудро, и потому не слишком активно использует буферизацию записи, всё-таки не очень приятно терять как-бы-уже-записанные-на-диск данные при внезапном отключении.

На сколько я понимаю, reprimand предлагает соорудить свою буферизацию из ramfs и скриптов. В принципе вариант, если памяти хватает.

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

Памяти можно докупить. Какой программе я могу указать работать с диском?

zm пишет кадры в: /var/www/zm/events. Посмотрите на вывод моих предыдущих команд, странно, но у меня при удалении повышается нагрузка на запись, но я думаю, что тут всё хуже, и zm запускает команду rm -rf. И из-за того, что она удаляет «покартинно» у меня всё проседает так.

И теперь самое главное: если у меня будет жёсткое выключение, то часом не превратится ли мой сервер в кирпич? - То что пропадёт часть данных - это хрен бы с ним. Там камеры не супер критичные. Но вот получить после жёсткого выключения - кирпич из /var/www/zm/events, куда более жёстко будет.

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

Меняется с 3 до 13. Согласен что конь в вакууме. Но изменение в более чем 4 раза.

Может каким-либо образом подкрутить zoneminder, что бы он не так «активно» чистил? Добавить еще диск и разнести 10 камер туда, десять сюда.

http://habrahabr.ru/post/169845/ вот оно. Но я вот думаю, а поможет-ли мне это..? Или мне правда лучше купить памяти просто побольше? Часть данных при внезапном ребуте - я готов потерять. Главное чтобы система потом поднялась.

И из-за того, что она удаляет «покартинно» у меня всё проседает так.

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

Сервер в кирпич превратиться не должен (хотя всегда есть способ сделать что-то неправильно). Не перекинутые на диск данные естественно превратятся в тыкву.

Не удобно. Тогда мне придётся писать камеры по разным дискам, и руками следить, чтобы ничего нигде не переполнилось... Штатных средств для ограничения аппетитов чистилки - я не смог найти. :(

Оно что, каждый кадр отдельным файлом сохраняет

Да. Каждый кадр это jpg файл. Делать сразу видео из кадров - я думаю что очень, очень дорого в плане CPU. И вестимо оно делает rm -rf на jpg файлы.

/var/www/zm/events/10/14/09/19/19/00/00# - минута - это каталог. В одном каталоге: ls |wc -l 2499 jpg файлов. Зависит от качества сети и fps

Сервер в кирпич превратиться не должен. Не перекинутые на диск данные естественно превратятся в тыкву.

Плевать на данные. Это не часто бывает. Вопрос в «сколько памяти докупить»? При моих командах. См. первый пост. И опять-же: Вы уверены, что это правильный путь и оно мне поможет в моём случае с кучей jpg файлов и rm -rf на них..? Ну и третий вопрос, как мне реализовать запись в каталог через ramdisk?

noatime,data=writeback,nobh,barrier=0,commit=300 — а вот такие опции народ предлагает для монтирования ext4. Якобы ядро в таком случае будет само писать в RAM используя свои кеши, и только потом будет реальная запись на диск. Что скажете?

Вы уверены, что это правильный путь

Не уверен

оно мне поможет в моём случае с кучей jpg файлов и rm -rf на них..?

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

Ну и третий вопрос, как мне реализовать запись в каталог через ramdisk?

Примонтировать tmpfs в директорию в которую программа пришет файлы, или научить программу писать файлы в директорию куда примонтирована tmpfs.

сколько памяти докупить

Зависит от того сколько данных в секунду сохраняет твоя программа и как долго ты хочешь их накапливать перед тем как сбрасывать на диск.
Кстати есть смысл при сохранении на диск склеивать кадры в один файл. Мне кажется что склейка mjpeg из jpeg-ов не особо ресурсоёмкая задача. Хард переварит такую запись гораздо легче, ибо запись последовательная.

сделай ему программный raid10 из чорных wd, озаботившись выравниванием разделов и тюнингом фс.

упд: и никогда не делай barrier=0 на данных, имеющих значение для окружающих людей, если у тебя контроллер дисков не подпёрт батарейкой.

ХЗ, попробуй. Но с кучей мелких файлов такой буферизации может быть недостаточно, ведь кроме самих данных нужно ещё и inode писать, а значит чисто последовательной записи не выйдет.

Ну да, камеры по разным дискам, и нагрузка тоже. Следить, что бы «ничего нигде не переполнилось» так же, как и сейчас.

Примонтировать tmpfs в директорию в которую программа пишет файлы

Это можно организовать, но вот вопрос, а как tmpfs поймёт куда скидывать данные в реале? Я уж явно не смогу купить 4тб озу же... Мне бы примаунтить tmpfs на 8гб. скажем. После чего скидывать периодически с него данные, но блин... - Не понимаю как мне это поможет. Ведь так или иначе, данные из tmpfs ВСЕГДА будут сливаться на HDD... Оно же наполнится и будет сливать.

С одним диском много, много проще. А если дисков будет много, мне надо будет городить на каждую камеру отдельный фильтр.

Вот и я так думаю... Что не всё так просто.

Вот и я думаю, быть может склепать ему RAID. А почему чёрные диски? Я думаю может взять нафиг: Toshiba DT01ACA200 , ну вылетит так и хрен с ним. Зато в 14к. можно уложиться. Просто много денег тратить на поделку в виде zoneminder нету большого желания.

Кстати есть смысл при сохранении на диск склеивать кадры в один файл. Мне кажется что склейка mjpeg из jpeg-ов не особо ресурсоёмкая задача.

Верю. Но так уж устроен zm. Его переделывать я не буду. :)

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

Таких параметров я не видел... И что будет, если tmpfs начнёт скидывать данные, когда у меня будет выполняться rm -rf? Может можно как-то динамически рулить? Когда выполняется rm -rf - тогда пишем всё в tmpfs, и только туда. Когда rm -rf убирается, тогда можно и убрать tmpfs вовсе.

потому что у тебя денег нет, судя по топику, а у чорных wd лучший баланс надёжности, скорости, цены и наличия в сельском магазине. Впридачу ко всему выкрути aam дисков в самый громкий режим.

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

Памяти можно докупить. Какой программе я могу указать работать с диском?

вы в шапке поста указали, что за программа у вас. Вот ей и указывайте.
Потом создайте запись в кронтаб, чтобы данные переносились на реальный hdd. А именно - в ваш /var/www/zm/events

Очистку места на HDD соорудите тоже на cron-е, скриптами, думаю, труда не составит

Вот вам и автоматизированное, высокопроизводительное решение

И теперь самое главное: если у меня будет жёсткое выключение, то часом не превратится ли мой сервер в кирпич?

вероятность превращения сервера в кирпич останется прежней

То что пропадёт часть данных - это хрен бы с ним.

со 100% вероятностью пропадет та часть данных, которая находится в ramdisk-е

А память таки докупите.

триллионы картинок у него. Так что небось надо журнал фс на ssd выносить.

и да, я таки не знаю что за дураки советуют кеширование использовать на SSD
да, SSD быстрее. И че?
Если так приспичит отдельный винт для кеширования (хотя, ОЗУ вышло бы на порядок дешевле и быстрее), лучше взять быстрый высокооборотный HDD на SAS

Нет потоков видео. Потоки только по запросу пользователя, если случается что-нибудь, то из web морды zm давится кнопка - получить avi. И оно пятиминутное видео генерит из картинок. :)

А что за фс на диске, ext4 я так понял?

Зачем вообще журнал в такой ситуации?

У меня не то, что бы нету денег... Просто zoneminder скажем так... - Решение в чём-то ОЧЕНЬ крутое, а в чём то очень глючное и ненадёжное... - При моём количестве разннобразных камер (порядка 50 штук), покупать мейнстрим решения - будет не бюджетно. Покупать вот такие штуки: http://www.ami-com.ru/item/Линия NVR-32 я боюсь... Ибо очень много подводных камней, такие дешёвые сервера запросто может потом оказаться, что более 640*480 оно не может и тому подобные фишки, плюс глюки софта от наших разработчиков... А хорошие решения стоят по 200к. Можно netavis рассмотреть, но это тоже не бюджетно.

По сему, мне хочется попробовать zoneminder, и если оно не получится - тогда купить что-то другое. Пока в целом zm устраивает, но косяки есть конечно...

Да. ext4.

Можно-ли поставить в качестве буфера, какую-нибудь SSD?

Ещё вариант — использовать SAS. Хотя по деньгам сегодня это уже не сильно дешевле SSD, но куда медленнее. Но при этом SAS на практике намного быстрее, чем SATA.

На SATA несколько помогает такое, но повышает риск потери данных при отказе питания, так что ИБП рекомендуется. Но он всегда рекомендуется :)

for dev in /sys/block/sd?; do
    echo 120 > $dev/device/timeout
    # http://www.monperrus.net/martin/scheduler+queue+size+and+resilience+to+heavy+IO
    echo noop > $dev/queue/scheduler
    echo 32768 > $dev/queue/nr_requests
    echo 8192 > $dev/queue/read_ahead_kb
done

echo N > /sys/module/drm_kms_helper/parameters/poll

Я пока не совсем хорошо понимаю, как мне использовать ОЗУ в качестве кеша... :(

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

Тут может помочь ionice на чистящий процесс. Если он конечно запускается отдельно.

Я пока не совсем хорошо понимаю, как мне использовать ОЗУ в качестве кеша... :(

Можешь даже не слушать в эту сторону. Кеш не спасет. Или точнее это лечение симптомов, а не причины.

Ой... То есть использование другого планировщика поможет? Кхм... Реально стоит морочиться с этим?

Так что небось надо журнал фс на ssd выносить.

Да отключить его нафиг совсем.

Да. Запускается отдельно. То есть в top скачет нечто: rm -rf /var/www/zm/events/bla/bla/bla но запускает процесс сам zm из своих кишочков, и по своим алгоритмам. Можно как-то сделать так, чтобы бинарный файл rm, ВСЕГДА имел низкий ionice?

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

То есть использование другого планировщика поможет? Кхм... Реально стоит морочиться с этим?

Когда CFQ только появился и на десктопе — это было просто реально офигенное чудо. Под самой высокой дисковой нагрузкой машина не затыкалась, окошки таскались плавно и т.п.: http://forums.balancer.ru/tech/forum/2006/09/t50753--cfq-io-schedule-i-proc-s...

Но шли годы, cfq работал всё хуже на десктопе, а на сервере, как показали мои последние тесты, он стал вообще источником постоянных затыков и тормозов. Меняешь cfq на noop или deadline — и iowait сразу падает, LA снижается, отзывчивость web-сервера возрастает. При чём очень сильно. Вот между noop и deadline принципиальной разницы не заметил. В каких-то случаях один лучше, в каких-то другой, но разница на уровне погрешностей измерения.