Сергей Пуговкин

зависит от настройки swappiness
типа ФС.
ну и на худой конец
vm.vfs_cache_pressure=50
vm.dirty_writeback_centisecs=15000
vm.overcommit_ratio = 100
vm.overcommit_memory = 1

Решил углубится в тему, вот результаты:

Директива open_file_cache применяется для кеширования информации о статических файлах: js, css, jpeg, html,..
Если файл не существует, или не прав на чтение, то эта информация также может хранится в кеше.
По умолчанию: open_file_cache off;

Пример с описанием:

# Информация о 1000 файлов, может хранится в кеше. Если не было активности к файлу в течение 5 мин, то информация о нем удаляется из кеша
open_file_cache max=1000 inactive=5m;  

# Активностью считается обращение к файлу хотя бы 2 раза. В кеш они также попадают, если было хотя бы 2 обращения к файлу
open_file_cache_min_uses 2;             

# Вся информация о файлах в кеше обновляться раз в 1 минуту
open_file_cache_valid 1m;               

# Сохранять ли информацию об ошибках, например, если файла, к которому вы обратились - нет, то это будет тоже в кеше, информация тоже обновится через 1 мин
open_file_cache_errors on;

При работе со статическими файлами, когда они изменяются, например верстке.
На время работ желательно отключать open_file_cache, либо параметр open_file_cache_min_uses делать достаточно большим, чтобы файл не попадал в кеш, но это фактически тоже самое что и отключить open_file_cache.

Если файл находится в кеше, при этом происходит изменение файла, то сервер выдаст ошибку ERR_EMPTY_RESPONSE, что значит, что сервер отказал в доступе и не отдал контент.
При этом сам сервер работает нормально и если обратится к другим файлам, то они легко загружаются.
Примечателен факт, что если восстановить измененный файл, то сервер его начинает отдавать до проверки open_file_cache_valid. Видимо проверяется контрольная сумма файла, так как дата изменения файла меняется.

При работе с файловой системой NFS, рекомендуется не включать open_file_cache, так как информация о файлах может не обновляться даже после open_file_cache_valid.

Написал, а то может кому интересно будет или я забуду :)

Не совсем.
Делают они одно и то же только для location /.

Если у вас, например, location /img, то при
root /var/www ссылка /img/1,jpg будет вести в файл /var/www/img/1.jpg

а при alias /var/www та же ссылка будет вести в /var/www/1.jpg.

В данном случае виртуальному серверу (VPS) присваивается некоторое имя - hostname, которое, как правило, задается на этапе установки OS но позже может быть изменено.
Для чего нужно имя (hostname)?
Во -первых для идентификации сервера, при большом парке серверов необходимо точно понимать, на каком серевере ты находишься. По этой причине hostname должен быть уникальным.
Во-вторых, для выполнения обращения к серверу по имени (удаленный доступ, авторизация на сервере, выполнение удаленных команд).
Для доступа к серверу по имени нужно чтоб это имя резолвилось (преобразовывалось в IP-адрес) со стороны адресанта. Это условие выполняется если:
- локальный DNS сервер адресанта резолвит hostname адресата;
- hostname прописан вручную в "/etc/hosts", тогда преобразование имени будет происходить без DNS сервера.
Следует отметить, что в OS Windows обращение к серверу возможно по hostname, тут будет работать механизм NetBIOS.

FQDN и Hostname могут как отличаться, так и быть идентичными.
Очень часто значение FQDN понимают как публичную DNS запись типа А ( A-record), это делает данную запись уникальной.
Однако FQDN может быть уникальным только в пределах определенного сегмента сети или домена, который обслуживается своим DNS.
Почему некоторое ПО проверяет fqdn?
Программное обеспечение выполнит резолвинг fqdn-имени и попробует сравнить полученный IP-адрес преобразования с ip-адресом самого хоста. Таким образом сверка IP-адресов может быть проверкой корректности настроек.
В описанном случае с 10-20 сайтами и почтой на каждом из них , следует понимать, что у каждого сайта есть своё доменное имя, которое сконфигурировано через VirtualHost. По этому можно рекомендовать указать fqdn которое соответствует hostname с доменным именем (проверить можно через команду "hostname -A") и при этом резолвятся в небходимый IP.

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

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

100% перегрет, но не программистами или веб-мастерами, а индивидами, которые решили что веб это просто и легко и не стоит сильно париться над своими скиллами и знаниями.

Основное достоинство PaaS и serverless архитектур как раз в лёгком и почти безграничном масштабировании.