Борис Сёмов

Основная разница в том, что надо следить ещё и за железом. Соответственно, неплохо бы знать, как это делать.

Скопировать не могу, но помню, что были случаи, когда помогало отключение Large Receive Offload(LRO). Но это было на довольно старых ядрах/драйверах.

Если у роутера есть такое ограничение, это, скорее проблема убогости интерфейса конкретного роутера. Пробростить технически можно 65536, ну чуть меньше портов. =)

В некоторых роутерах можно пробрасывать не по одному порту, а диапазонами, возможно, в вашем случае это решит проблему.

Также в некоторых роутерах можно настроить DMZ, и возможно, это решит вашу проблему.

Если у вас достаточно знаний, чтобы работать с прошивками этих устройств, то такой вопрос у вас бы не вставал. И тем более небыло бы никаких мыслей о запуске какой-то игры на этой платформе. А т.к. вы ничего в этом не понимаете, никто не сможет в формате вопрос/ответ вас обучить необходимому. Это годы обучения, и масса информации, которую нужно перелопатить по каждой конкретной платформе.

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

Потерянные/повреждённые файлы, это не к слою raid, который работает с блоками, и ничего не знает о ваших файлах, а к слою файловой системы, которая на нём.
Так что смотрите в сторону fsck и подобных инструментов.

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

Под Linux использую Remmina, примерно аналогично.

Том на DO это подключённое блочное устройство. Его можно отформатировать в какую-нибудь ext4 или xfs, и смонтировать как папку внутри вашего webroot, например, туда, где надо сохранять много всего.
Или вообще перенести на него полностью сайт/сайты, оставив основной диск системе и базе данных, например.

Именно объединение объёмов, с ним, в одной файловой системе довольно заморочно -можно использовать UnionFS|Aufs, но чаще всего это не нужно, и можно обойтись просто монтированием в нужный каталог.

Вероятнее всего это был сервер терминалов: https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%80%D...

Ставьте в режиме AHCI с софтовым raid через mdadm.
В принципе, такой контроллер, не стоит использовать как рейд контроллер - проблем больше чем с софтовым, а достоинств никаких - это не какой-нибудь навороченный рейд контроллер мощным процом, пачкой памяти и батарейкой, который действительно может дать заметный прирост скорости...

Разбирать user agent на уровне iptables не лучшая идея - там проверку будет проходить каждый пакет и это будет весьма накладно по ресурсам. К том же, это не будет работать для https.
Блокировку по user agent можно делать на уровне веб сервера.
Или логировать веб сервером попытки, и блокировать через iptables с помощью fail2ban, например уже по адресу.

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

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

Ошибки памяти далеко не всегда носят постоянный характер. Например состояние ячейки может изменить заряженная частица какая-нибудь.
Работайте дальше, если сбой будет повторяться, вернитесь к тестированию.

Также, можно проверить стабильность питания и качество контакта модулей памяти.

Я думаю, ваша ошибка о превышении количества обработчиков не связана с проблемой, которую вы пытаетесь решить. На это намекает "ERR_CONTENT_DECODING_FAILED". Вот тут, например почитайте в конце: https://dev.1c-bitrix.ru/support/forum/forum32/top...

MaxRequestsPerChild ставить не стоит - лучше где-то 500-1000(это количество запросов, которые последовательно обрабатывает один процесс-обработчик, прежде чем будет перезапущен, и ограничивается он для борьбы с утечками памяти).

MaxClients выставлять больше чем ServerLimit нет смысла. И то, и другое нельзя выставлять слишком большим - у вас должно хватать памяти на то, чтобы запустить столько процессов, и чтобы остальной софт на сервере тоже мог работать. Если количество процессов будет слишком большим, это может быть хуже, чем их недостаток...

Можно из командной строки запустить munin-run <название плагина> и посмотреть вывод.
Возможно не хватает каких-либо библиотек для плагинов, возможно что-то не настроено и.т.п.
Если вывод будет правильным, стоит посмотреть логи munin-upate.

Для этого есть разные инструменты, начиная с Chef, Puppet, и других систем управления конфигурациями, и заканчивая shell скриптами, написанными под свою конкретную задачу.