Сергей Протько

Порча от swap - это миф?

Давайте так. Порча от swap - это миф. Порча от частых перезаписей - не миф. Ячейки деградируют, SSD портится... со временем. Для домашнего ноутбука это время вполне может быть больше средней жизни ноутбука у человека.

Если у вас мало оперативки - swap на ssd вполне себе нормальное решение. Но только это будет означать что использоваться он будет намного более интенсивно нежели в системах с большим объемом памяти.

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

как бы ты сделал отказоустойчивый LAMP кластер для высоконагруженных WEB-приложений?

по поводу производительности

1) пишем нагрузочные тесты
2) прогоняем их и ищим узкие места и думаем что нам с этим делать
3) устраняем узкое место
4) повторяем пункты 2 и 3 до тех пор, пока не получаем приемлимые для нашего приложения цифры (ну то есть что бы удовлетворяло нашим ожиданиям по нагрузкам, это к слову тоже стоит заранее прикинуть с учетом неравномерности распределения пользователей и т.д.).

ПО поводу надежности:

ищим single point of failure. ну то есть если у нас есть база данных - то ее должно быть две на случай если один сервак выйдет из строя. А еще должен быть сверху балансировщик который раскидывает запросы. А что бы невилировать вероятность того, что и балансировщик выйдет из строя - балансировщик на уровне DNS.

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

отдавайте все через nginx, повесьте apache на порт 8080 например (или вообще любой доступный) и запросы на конкретные сайты просто проксируйте на apache.

все зависит от того что вы с этими данными делать будете. Если просто хранить - то выдержит конечно. Если делать сложные выборки - то зависит от нагрузки и количества запросов а так же расставили вы индексы или нет ну и все такое. Ну и для такой выборки памяти под индексы надо прилично и тюнить настройки mysql.

Если вас интересует как ускорить запись - можно сначала загонять все в буфер (redis например) и потом пачками заносить все в базу.

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

syslog + bash

Vagrant, Docker

если в первый раз настраиваете сервак - лучше debian или ubuntu, банально проще.

www.mono-project.com

что вам еще надо? Чуваки из мелкософта туда активно контрибьютят, серсы пооткрывали (постепенно, это довольно длительный процесс учитывая масштабы продукта), vnext вон вроде обязались даже тестить под моно.

MY_MAC=$(tail -n2 | head -n1 | tr -s " " | tr -d \' | cut -f3 -d " ")
etherwake -i br-lan "$MY_MAC"

Потому что так гласит стандарт IEEE802.3

На самом деле все просто, при таком максимальном размере датаграммы она достаточно маленькая что бы время ее доставки было не критичным (особенно в случае потерь), но и достаточно большая что бы минимизировать оверхэд на канальном уровне.

Предположим что мы хотим послать IP датаграмму в 1500 байт. Это мы еще находимся на третьем уровне модели OSI. Теперь идем на второй, запаковываем датаграмму в ethernet-фрейм, то есть добавляем еще 26 байт, итого имеем фрейм размером в 1526 байт. Так же между всеми фреймами есть еще 12-ти байтный зазор, что бы различать где кончается один фрейм и начинается другой. То есть на каждую датаграмму в 1500 байт мы передаем фрейм в 1538 байт.

Давайте пока не будем отвлекаться на всякие Fast Ethernet и примим что скорость нашего Ethernet - 10mbps. Посчитаем сколько фреймов может передаваться в секунду:

10 Mbps / 1538 байт = 812.74 фреймов / секунду.

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

812.74 * 1500 = 9 765 625 bps или ~9.7Mbps что есть ~97% заполнения канала. Логично что если повысить MTU то и полезная нагрузка будет больше, но тут стоит просто иметь в виду еще и потери пакетов и прочее. В этом плане маленькие пакеты лучше, в итоге приходим к компромису.

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

Рекомендую почитать: en.wikipedia.org/wiki/Jumbo_frame