Алексей Черемисин

Вынесу в ответ на подсказку chupasaurus:
Police-based routing
- habrahabr.ru/post/101796 - часть 1
- habrahabr.ru/post/114197 - часть 2

А чего приводить... Когда есть куча подсетей в одной сети. Например, притащили новую железку, а у нее подсеть по умолчанию не та. Или в малом офисе удобно не разносить по vlan всякие коммутаторы и точки доступа, а просто прописать им отдельную подсеть. Да куча всего, где это может понадобиться, даже для распределения нагрузки!
А вас в ipv6 не смущает количество IP-адресов на одном интерфейсе?

Если на питоне, то рекомендую twisted+cyclone (аналог торнадо) или само tornado. Тут вам и сервер, причем очень быстрый и блоки для приложения (twisted).
Единственная проблема с twisted - баг 288 (в багтреккере), это относится к большим файлам при их раздаче и получении (они должны помещаться целиком в память). Ну и как вариант, есть куча решений, например - sammitch.ca/2013/07/handling-large-requests-in-twisted
Если на java - используйте netty.io
PHP я бы не стал использовать, а про ASP ничего не скажу.

Я за java и питон с twisted+cyclone! Причем если нужно действительно быстро - то только java+netty из всего набора.

Ну а вообще-то можно и на lua под nginx, если сервис относительно простой.

Конечно можно! Более того, очень часто так и делают, что конечно не очень правильно.
1. Необходимо следить за кешированием и подразумевать, что оно может быть в любом приложении, иначе можно получить невалидные данные.
2. Лучше писать в базу только из какого-то одного приложения, остальные читают, иначе П1.
3. Вообще-то так делать не очень хорошо, из-за возможности потери консистентности данных, если несколько приложений пишут одновременно.
4. очень трудно поддерживать изменения в коде и в структуре базы, когда изменения в одном приложении автоматически сказываются на всех остальных.

Как правильней делать?
Для данных пишется враппер(приложегние) типа веб-сервиса, через который все и работают с базой и ее данными! Или само приложение реализует вебсервис. json - рулит.

Добавить в загрузку сессии
xhost +

Для web-программирования подойдет абсолютно любой компьютер. Даже если будете запускать виртуалку. Я бы правда памяти нарастил, но и так пойдет.

Конечно, сейчас скажут, что без SSD, монитора в 30'' и памяти в 32 гига вам просто не жить. Нормально. У меня эклипс, ява, пара виртуалок, куча какого-то говна запущена прямо сейчас. Core2Duo (!), 8Гб памяти и 256Gb обыкновенный HDD (не SSD). Все нормально работает и не тормозит. Правда это макбук wihte 2009 года.

Да, на основное рабочее место купите монитор в 22'' при случае, но это у меня дома, а дома я не работаю!

Да, будет. Только и энергии жрать будет как два винта. На ноутбуках, думаю, смысла нет.

А используйте LXC контейнеры (про сетевую загрузку по PXE вам написали уже). Контейнеры не требуют виртуализации, а профита как от полноценных виртуалок.

А запросы оптимизировать не пробовали? индексы там строить? проверить на медленные запросы? вдруг у вас там индексы (если они есть), не работают?
habrahabr.ru/post/31072

Открою страшную военную тайну, в линуксе, да и в остальных файловых системах принято записывать время последнего обращения к файлу (каталоги и т.д.), называется она atime (access time). Эту фичу можно отрубить в fstab, прописав в опциях монтирования noatime. Есть еще опция nodiratime, но она автоматом включается при noatime.

А если вообще не хотите ничего писать на диск, то используйте или overlayfs или aufs, а корневой раздел монтируйте в readonly. Для ubuntu можно здесь почитать - https://help.ubuntu.com/community/aufsRootFileSyst...

PS. До кучи - www.digitalinternals.com/unix/linux-io-performance...

Если сервер имеет BMC, а должен по идее, иначе какой он сервер. То попросить провайдера подключить его к сети по vpn или еще как. Тогда и провайдера просить не нужно, и можно посмотреть что в консоли происходит. А происходить может обыкновенный кернел-трап, дамп которого можно увидеть только с консоли.
Ну и если у нас недосервер без BMC, то при очередном фейле попросить фото консоли. Ну и логи удаленно писать и статистику собирать через collectd + influxdb + grafana.
Сервера перестаю на ssh отвечать из-за аппаратных проблем обычно. Ны а сами проблемы, от дисков до памяти в промежутках адаптеры, процессоры, далее везде.
Ах, еще может быть кернел дидлок, но это только в консоли смотреть. А еще может и драйвер какой кривить...
Для удаленных логов и статистики арендуйте долларов за 5 виртуалку где нибудь на DO.

Все очень просто, берете виртуалбокс, а лучше vmware player, он бесплатный, идете и тащите готовый образ отсюда www.osboxes.org/debian
Далее в системе под рутом вызываете tasksel и выбираете любимый lamp. Успехов в правильном начинании.

Э... Извиняюсь, если ломают, то дело, конечно не в обновлениях. А в... ну... э... руках.

Чтобы не ломали, точнее, ломали, но безболезненно, используйте виртуалки/контейнеры, файерволы, прокси... Ну и накатывайте обновления по мере их выхода.

При взломе политика такая - восстановить последнее в режиме read-only, вручную накатить обновления.

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

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

И да, с контейнерами/виртуалками сайт лечить одно удовольствие.

Как вариант предлагаю:
Севрвер с тройкой виртуалок, одна под мускуль, вторая под нгинкс, третья под php-fpm. Сам сервер настраиваем на проброс всего http на nginx, закрываем его по самые яица и коннектимся к нему в двух-трех IP.
Виртуалка с nginx работает только со статикой и отдает остальное на php-fpm.
php-fpm коннектится к базе мускула.

Если что-то сломали, то просто восстанавливаем последний снапшот в режиме реад-онли. Ну и всегда держать виртуалку со статикой "Ведутся работы"...
Тоже самое - на LXC или docker делается, если виртуалки напрягают...

Ну и хорошо бы все php-файлы в режиме read-only держать.

Идей собственно две (ух - три):
1) Карточка впадает в сон - смотреть настройки драйвера, настройки ОС и БИОС в плане экономии энергии. Собственно по симптомам очень на это похоже.
- как проверить - подключить напрямую к компу/ноуту
2) Фиговый кабель и/или плохо обжат - здесь переобжать/поменять каблю
- пройти к коммутатору и подключить вместо него комп/ноут, iperf поможет измерить скорость, измерять в течении 600 секунд (10 мин), статистика карты покажет ошибку
3) Выгорел порт на комутаторе/сетевухе - поменять порт/сетевуху
- см пункт 2), а после этого вставляем каблю в другой порт/сетевуху.

Образы виртуалок по iSCSI (мы правда напрямую через ceph это делаем), остальное, что для общего доступа - по NFS.
Мы делаем общий образ с системой, и делаем с него снапшоты на каждый инстанс виртуалки. Отдаем снапшот в виртуалку как блочное устройство. Если в каком-от инстансе нужен отдельный диск с данными, то его отдаем отдельно. Также часто делаем блоковые устройства для боольших временных файлов, тоже цепляем отделным диском в инстанс.