LINUX.ORG.RU

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


1

1

Друзья, имею сервер zoneminder, с 23 камерами. Планирую ещё десяток другой камер на него нацепить. Сейчас стоит один диск 4ТБ. Модель: WD40EFRX - я так понимаю оно 5400 об/мин?

Когда zoneminder запускает чистку дискового пространства, я имею вот такой УЖАС, при том la, прыгает до 13! iostat:

2014-09-19 16:44:01 Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
2014-09-19 16:44:01 sda               3,10  2165,30   68,30  564,50   300,00 15356,00    49,48    48,05   76,32   19,81   83,16   1,54  97,36

Когда я просто на него записываю, это выглядит примерно так:

2014-09-19 17:02:33 Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
2014-09-19 17:02:33 sda               0,80   136,30    1,80   71,30    15,60  5725,20   157,07     0,83   11,29   12,67   11,25   2,27  16,56

Как наиболее дешевле, понизить %util ? Можно-ли поставить в качестве буфера, какую-нибудь SSD? Или быть может купить три диска по 1,5 ТБ, но со скоростями шпинделя 7200 и таким образом размазать %util , объеденив их в RAID0? Поможет мне это?

Куда копать в общем?

Может кто-то использовал SSHD или EnhanceIO?

★★★★★

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

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

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

MrClon ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DALDON ★★★★★ ()
Последнее исправление: DALDON (всего исправлений: 1)

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

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

Так-так... - ОЗУ на сервере есть как минимум 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
DALDON ★★★★★ ()
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

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

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

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

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

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

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

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

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

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

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

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

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

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

DALDON ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

DALDON ★★★★★ ()
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от MrClon

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

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

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

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

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

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

Не уверен

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

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

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

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

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

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

MrClon ★★★★★ ()

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

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

dr-yay ★★ ()
Последнее исправление: dr-yay (всего исправлений: 1)
Ответ на: комментарий от DALDON

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

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

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

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

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

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

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

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

DALDON ★★★★★ ()
Ответ на: комментарий от dr-yay

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

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

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

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

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

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

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

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

dr-yay ★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

dr-yay ★★ ()

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

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

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

DALDON ★★★★★ ()

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

stave ★★★★★ ()
Ответ на: комментарий от dr-yay

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

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

DALDON ★★★★★ ()

Можно-ли поставить в качестве буфера, какую-нибудь 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

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

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

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

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

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

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

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

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

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

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

DALDON ★★★★★ ()
Ответ на: комментарий от dr-yay

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

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

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

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

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

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

dr-yay ★★ ()
Ответ на: комментарий от DALDON

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

Когда 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 принципиальной разницы не заметил. В каких-то случаях один лучше, в каких-то другой, но разница на уровне погрешностей измерения.

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