>>Nagios - это система промышленного, я бы сказал, масштаба.
>извините но почему эта система промышленного масштаба использует в качестве хранилища не
>СУБД, а файловую систему? Это что быстрее ? Практика показывает, что
>нет. А еще мне понравились их предложения по повышению производительности. Вынести
>файловое хранилище системы мониторинга на RAM-диск это что-то! И что самое
>главное надежно в промышленной эксплуатации. Давайте уйдем от аксиомы гласящей, что если не используется СУБД, то программа плохая и разберемся в вопросе чуть более детально. Итак у нас есть хосты и сервисы (объекты мониторинга). У каждого объекта есть ряд аттрибутов, которые изменяются во времени и, которые необходимо хранить не только в памяти, но и на жестком диске, что бы не потерять данные о текущем состоянии объектов в момент перезапуска программы. Согласитесь, что было бы накладно при каждом перезапуске программы заново составлять базу состояний, учитывая если кол-во объектов десятки тысяч. Теперь оценим размер этой базы состояний на примере Nagios. Nagios хранит базу состояний в текстовом файле status.dat (этот файл используют cgi скрипты) и в retention.dat в примерно следующем формате:
объект {
аттрибут1 значение
аттрибут2 значение
...
аттрибутN значение
}
У Nagios 2.0b3 объекты host и service файла status.dat занимают в среднем 1К каждый (чуть больше или чуть меньше в зависимости от plugin_output и других переменных величин типа host_name или service_description). Получается что при суммарном кол-ве объектов мониторинга в 45000 (см. Top 5 Installations выше) требуется памяти не более 50Мб (столько требуется дисковой памяти, а что касается ОЗУ, то гораздо меньше, ведь там не надо тратить байты на названия аттрибутов).
Сам демон не производит никакого парсинга файлов status.dat и retention.dat в процессе работы, ему это не надо. Один раз при запуске считывается retention.dat. В процессе работы переодически делается дамп базы данных состояний из оперативной памяти в файлы на HDD. Для retention.dat можно вообще указать, что бы в него скидывался дамп лишь в момент останова демона. По-умолчанию дамп в retention.dat делается один раз в минуту. Что касается status.dat, то по-умолчнию один раз в 15 секунд (задается опцией status_update_interval в главном конфиге). Что бы записать 50 Мб на винт обычного IDE винчестера требуется не более 2-3 секунд и ресурсы процессора в этой операции практически не задействуются.
Теперь представьте, что Nagios использовал бы СУБД. Это значит, что каждый раз, если меняется состояние объекта, надо сделать один или несколько запросов, типа:
UPDATE hosts SET аттрибут1=значение WHERE host_id=12312
UPDATE hosts SET аттрибут2=значение WHERE host_id=12312
...
UPDATE hosts SET аттрибутN=значение WHERE host_id=12312
СУБД тратит процессорное время на отработку каждого запроса, в то врмя как процессор и без того занят работающими в данный момент плагинами, а попробуйте посчитать какова будет загрузка при 45000 объектов мониторинга?
Вывод: с точки зрения производительности использовать текстовый файл, а не СУБД выгодней.
