Что лучше в плане безопасности и стабильности + по ресурсу ,Ubuntu server или Cent OS??

El6 имеет ядро 2.6.3, а никак не 2.2

Как правильно вычислять vm.dirty_background_bytes и vm.dirty_bytes?

Антон Пацев, я предлагаю подбирать их экспериментально, с обязательным замером производительности и анализом результатов этих замеров. Для себя лично я придерживаюсь стратегии "Преждевременная оптимизация — зло" (да, там в основном про программирование, но переложить принципы на администрирование можно).

Как правильно вычислять vm.dirty_background_bytes и vm.dirty_bytes?

dirty_background_bytes и dirty_background_ratio взаимозаменяемые параметры. Разница между ними в том, что dirty_background_bytes указывается в абсолютных байтах, а dirty_background_ratio в процентах от доступной (available) памяти. dirty_bytes и dirty_ratio точно так же взаимозаменяемые. Причем если мы вручную выставляем значение vm.dirty_bytes, то vm.dirty_ratio обнуляется, а если выставляем vm.dirty_ratio, то обнуляется vm.dirty_bytes (dirty_background_bytes и dirty_background_ratio ведут себя аналогично по отношению друг к другу).

Это очень легко проверить, по умолчанию vm.dirty_bytes = 0, а vm.dirty_ratio равен 20 (на моей убунте). 2 вызова echo и 3 вызова sysctl все раставляют по своим местан без непонятных фраз "Если dirty_bytes установлено, dirty_ratio становится функцией к этому значению"

yukra-ThinkPad-Edge-E330 ~ # sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
yukra-ThinkPad-Edge-E330 ~ # echo 4194304 > /proc/sys/vm/dirty_bytes 
yukra-ThinkPad-Edge-E330 ~ # sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 4194304
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 0
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
yukra-ThinkPad-Edge-E330 ~ # echo 20 > /proc/sys/vm/dirty_ratio 
yukra-ThinkPad-Edge-E330 ~ # sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
yukra-ThinkPad-Edge-E330 ~ #

По поводу назначения: dirty_ratio или dirty_bytes устанавливают максимальное колво памяти, которую можно использовать под dirty page (в процентах или байтах соответственно). dirty_background_ratio и dirty_background_bytes устанавливают порог, если кол-во dirty page окажется выше этого порога, то ядро ОС начнет синхронизировать эти dirty page на диск.

У вас в примере vm.dirty_background_bytes и vm.dirty_bytes постоянно меняют значение - эти значения выставляются 1 раз и не меняются ядром автоматически.

Да, согласен, правильно было-бы использовать термин "кол-во dirty page в данный момент". В момент когда я писал, мне показалось очевидным, что под vm.dirty_bytes в примере имеется ввиду не число, выставленное через sysctl, а кол-во данных в памяти, которые используются как dirty page.

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

Почему тоже на кого-нить сошлюсь:
Рекомендации IBM (ссылка 10 страница).

To influence the management of page cache on the Linux server, tuning the parameters vm.dirty_ratio and vm.dirty_background_ratio is important. A good starting point is usually to set vm.dirty_ratio:10 and vm.dirty_background_ratio:5.

Рекомендация от Redhat(ссылка)

dirty_ratio
Defines a percentage value. Writeout of dirty data begins (via pdflush) when dirty data comprises this percentage of total system memory. The default value is 20.
Red Hat recommends a slightly lower value of 15 for database workloads.

dirty_background_ratio
Defines a percentage value. Writeout of dirty data begins in the background (via pdflush) when dirty data comprises this percentage of total memory. The default value is 10. For database workloads, Red Hat recommends a lower value of 3.

(да, эти значения меньше дефолтных, но они не зажимают дисковую подсистему в минимальные 2-4-8Мбайт)
От себя лишь хочу сказать добавить что вы не сможете записать данные быстрее, чем ваши диски могут это сделать, для обхода dirty page существуют свои техники, такие как открытие файла в синхронном режиме, и этим активно пользуются СУРБД (если настроены соответствующим образом), а сильное занижение vm.dirty_ratio ничего кроме лишней нагрузки на дисковую подсистему не вызовет, ведь не оставит ядру ОС "пространства для маневров" . Комментировать ссылку на ЛОР не вижу смысла, там нет никаких технических подробностей (начиная от того, что не указана система виртуализации и тип дисков и заканчивая тем, что проблема может быть в южном мосте, через который идет общение и с дисками и с клавиатурой).

Зы vm.dirty_ratio считается от доступной (available) памяти, а не от установленной в сервере.
Зыы "у нас есть еще много серверов с CentOS 6" тогда просто правим /etc/sysctl.conf

Как правильно вычислять vm.dirty_background_bytes и vm.dirty_bytes?

Плюс вышеупомянутый fsync. Ситуация примерно такая: если приложения говорит операционке "запиши в файл эти данные", то ОС отвечает "готово, все записанно" в тот момент, когда фактически данные попадают в dirty page. Если между попаданиями данных в dirty page и фактической записью данных на диск что-то пойдет не так (например пропадет питание и сервер выключится), то данные из dirty page пропадут. При этом помним что данные по умолчанию в dirty page могут пролежать "около 30 секунд + время необходимое для из переноса на диск", то есть достаточно долго. Вызов же fsync (после записи в dirty page) говорит ОС примерно следующее: синхронизируй вот этот файл на диск, а не в dirty page и скажи когда закончишь. И как правило все СУБД вызывают fsync по несколько раз на одну транзакцию. Причем обычно после завершения транзакции СУБД вызывают fsync и только после его завершения сообщают клиенту "транзанкция завершена успешно". В случае postgresql за это поведение отвечают параметры fsync, synchronous_commit, wal_sync_method, full_page_writes и некоторые други в конфиге сервера.

То есть с настройками по умолчанию большинство СУБД используют dirty page по минимому (тут стоит сделать две ремарки: 1. Если поменять нужные параметры так, что бы dirty page использовался "намного больше", то это увеличит производительность СУБД, но в случае сбоя, того же пропадания питания например, возможны потери данных из некоторых последних транзакций или неисправимой порче всей базы данных 2. Вызов fsync в общем случае ничего не гарантирует. Он может не "иметь нужного эффекта", если используется hardware raid-контроллер с включенным кэшированием, если ОС работает в виртуалке и ОС общается не с "физическим диском, а с виртуальных", если используется какая-либо умная СХД и т.п. Выполнять ли реальный fsync или игнорировать можно настроить на каждом из этих уровней). В итоге, в общем случае я бы рекомендовал не менять параметры, которые вас интересуют, а использовать значения по умолчанию. Если очень хочется "тонко потюнить" эти параметры, то только путем замеряем текущую производительность, изменяем один параметр, повторяем замеры, сравниваем их результаты и принимаем решение", и как говорил уже выше всегда стоит помнить что смена профиля нагрузки (замена "реальной" нагрузки на синтетические тесты) может перевернуть результаты тестов и выводы на строго противоположные.

Если так, то как лучше вычислять скорость запись на диск?

На сколько я понимаю в вашем случае (разработка аналога mysqltuner для postgres) замерять скорость диска не нужно. Диск уже есть (не важно это один hdd sata, маленький кусочек стораджа в облаке за 3$ или целая большая энтерпрайзная СХД за 100500 денег). Диск уже есть, на нем уже установленна ОС, лежат данные и т.п. Вам осталось работать с тем, что есть, а не писать пользователю "ваш диск медленный, купите all flash схд"

В большинстве случаев важна скорость случайной записи - верно?

Сильно зависит от характера нагрузки и от требований к надежности баз. В некоторых случаях можно пожертвовать fsync'ами на каждую транзакцию, тем самым повысим производительность и тем самым сместив акцент в сторону "важности скорости случайного чтения". А скорость случайного чтения часто можно компенсировать размером доступного кэша под это самое чтение (читайте - размером ОЗУ). Но так нельзя говорить "в общем случае", только разбирая конкретные случаи.

Как вы вычисляете vm.dirty_background_bytes и vm.dirty_bytes (на установленном Linux - без переустановки)?

А чем вас значения по умолчанию не устраивают?
Что бы проверить текущие значения: sysctl -a | grep vm.dirty
Что бы установить новые значения можно воспользоваться systemd-sysctl
Зы не то, что хочу вас упрекнуть или задеть, но вы не думали что начиная подобный проект вы должны брать на себя некоторую ответственность за выдаваемые рекомендации. А вы спрашиваете "какие значения выставить вот этим параметрам" что бы на основе ответов потом что-то кому-то рекомендовать, при том, что сами не очень понимаете как и на что эти параметры влияют. В итоге как минимум можете сбить человека с правильного пути (по оптимизации именно его БД), а как максимум он доверив вам выставит себе неподходящие параметры и не сомневаясь их верности будет пытаться добиться улучшения результата пытаясь править нетронутые вами параметры.
Причем я посмотрел проект, который вы переписываете (postgresqltuner.pl) и там я не нашел никаких советов по правке vm.dirty* параметров.
Я бы советовал вам как минимум "не давать советов", в которых вы не уверенны на 100% и не проверили на личном опыте в разных ситуациях. Лучше ничего не сказать(или сказать "попробуйте поиграть параметром X"), чем выдать неверную рекомендацию тоном знатока.

Как настроить nginx + apache для скрипта парсинга?

На первый взгляд все правильно, попробуйте заменить '60m' на '3600s' и проверьте что в заинклюденных файлах ничего не переопределяется.

Управление мониторами без X-ов в Ubuntu 12.04 LTS

Настройки БИОСа смотрели? Там обычно можно отключить «встроенный» монитор.