Юрий

1) проверьте что "выше" по конфигу, например в разделе http или в каких-то его инклюдах не встречаются директивы proxy_cache ("nginx -T" покажет полный конфиг)
2) если п.1 не поможет, то смотрите в инструментах разработчика браузера (F12 обычно) получаете ли вы этот "старый комментарий" с сервера или может быть он берется из локального кэша браузера. Особое внимание стоит обратить на заголовки Expires и Cache-Control, как между браузером и nginx, так между nginx и конечным сервером.

Сложно ответить без указания ОС, о которой идет речь (или указании конкретного репозитория). Но у оракла в данный момент есть 4 редакции mysql: MySQL Standard Edition, MySQL Enterprise Edition, MySQL Cluster CGE и MySQL Community Edition. При этом MySQL Community Edition - бесплатен, остальные - нет. Отличия в основном в "фишках, интересных бизнесу" (поддержка, лицензия, некоторые плагины). В обычном же интернете под mysql-серверов как правило имеют ввиду бесплатный MySQL Community Edition.
Подробней тут или тут (тут более понятно написано, но страница не официальная, могут быть неточности).
С mysql-community-server вроде разобрались, а пакет mysql-server скорей всего, это метапакет, на который ставят зависимости (если в репах имеется например mysql и percona, то что бы не привязываться в конкретной реализации делают примерно так: пакет mysql-community-server по зависимостям ставит пакет mysql-server, пакет percona-community-server так же по зависимостям ставит пакет mysql-server. При этом у всего софта, которому нужен mysql-server в зависимостях проставляется не mysql-community-server или percona-community-server, а тот самый метапакет mysql-server. В зависимости от ОС и пакетного менеджера могут быть нюансы, но обычно как-то примерно так).
Зы как понимаете все выше - попытка угадать, реальность может оказаться совсем другой, но выяснить это без понимания о каких именно пакетах в какой ОС идет речь невозможно, во всяком случае пока из отпуска не выйдут те самые телепаты.

Подозреваю что вам помогут данные из документации. То есть в конфиг нужно написать

[persistent_connection]
connect_timeout = 60
command_timeout = 55

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

Многое от ОС зависит. С большинстве ОС umask определяются в /etc/bashrc и ~/.bashrc, в /etc/profile и ~/.profile, в файле /etc/login.defs.
Мой любимый способ: через pam, в файл /etc/pam.d/common-session (debian\ubuntu, или другой в зависимости от потребностей) добавляем строку типа
session optional pam_umask.so umask=0022

Приемущества перед bashrc и bash_profile в том, что запуск bash не обязателен (эти настройки сработают если например залогиниться через scp или через ftp-server без запуска bash).

location можно задать префиксной строкой или регулярным выражением. Регулярные выражения задаются либо с модификатором “~*” (для поиска совпадения без учёта регистра символов), либо с модификатором “~” (с учётом регистра). Чтобы найти location, соответствующий запросу, вначале проверяются location’ы, заданные префиксными строками (префиксные location’ы). Среди них ищется location с совпадающим префиксом максимальной длины и запоминается. Затем проверяются регулярные выражения, в порядке их следования в конфигурационном файле. Проверка регулярных выражений прекращается после первого же совпадения, и используется соответствующая конфигурация. Если совпадение с регулярным выражением не найдено, то используется конфигурация запомненного ранее префиксного location’а.

https://nginx.ru/ru/docs/http/ngx_http_core_module...

Скорей всего запрос к phpmyadmin/index.php уходит не в "location ~ /phpmyadmin/(.+\.php)$", а в "location ~ \.php$" (потому что первое совпадение для location с регулярным выражением).
Посмотрите или тут (рекомендации непосредственно от Игоря Сысоева по написанию конфигов) или тут (там есть непосредственно пример конфига для сайта, который лежит по своему root-адресу и phpmyadmin по своему root-адресу).

У меня ответ больше 10000 символов. Тостер его не пропускает, поэтому разобью его на ответа:

Я так понимаю что для плавной работы Linux сервера, для плавной записи грязных страниц нужно поправить параметры vm.dirty_background_bytes и vm.dirty_bytes до соразмерных с величинами скорости записи на диск?

Нет. vm.dirty_background_bytes - сколько байт можно занять под dirty pages до того, как эта память начнем автоматически синхронизироваться на диск. vm.dirty_bytes - сколько всего байт можно занять под dirty pages.

Например у вас выставлен vm.dirty_background_bytes = 10, vm.dirty_bytes = 30, скорость записи на диск 2 байта в секунду, а скорость записи в ОЗУ 5 байт в секунду (все специально такое маленькое, что бы наглядно было понятно что происходит и не путаться в переводе значений из байт в мегабайты, байт в секунду в мегабиты в секунду и т.п.).
(Сделаем оговорку что dirty pages работает намного сложнее, чем описанно ниже. Он работает со страницами, а не с байтами, он имеет привязку к конкретным файлам и еще куча нюансов. Ниже очень упрощенный вариант объяснения, что бы получить примерное представление о том, что вообще происходит).

В Секунду 0 (начало примера) vm.dirty_background_bytes = 0, диск полностью простаивает и ничего не происходит (опустим момент что linux многопоточный и такая ситуация почти нереальна в реальной жизни). Вдруг какой-то процесс начинает писать что-то на диск, фактически он изменяет данные в ОЗУ и помечает страницу как dirty page, фактической записи на диск не происходит (если не происходит вызов fsync, но об этом ниже).
То есть через секунду, в секунду 1 у нас расклад такой: vm.dirty_background_bytes = 5 (скорость записи в ОЗУ ведь равно 5, дальше будет предполагать что процесс всегда будет писать с этой скоростью, потому что например ему нужно многое записать и все данные к этому уже подготовленны), vm.dirty_bytes = 5 (vm.dirty_bytes - это доступный для dirty page объем памяти, vm.dirty_background_bytes - это часть от vm.dirty_bytes), скорость записи на диск = 0.
Следующая, 2 секунда: vm.dirty_background_bytes = 10, vm.dirty_bytes = 10, скорость записи на диск = 0.
Следующая, 3 секунда: vm.dirty_background_bytes = 15, vm.dirty_bytes = 15, скорость записи на диск = 2 (vm.dirty_background_bytes превысил установленные нами условные 10 байт и запускается процесс синхронизации, он выбирает на скорость 2 байта в секунду (как мы условились выше) данные и пишет их на диск) (тут можно спорить в какой именно момент запуститься процесс синхронизации dirty pages на диск, когда vm.dirty_background_bytes будет 9, 10 или 11, но в данном случае этот вопрос не принципиальный).
Следующая, 4 секунда: vm.dirty_bytes = 18 (+5 записал процесс, -2 синхронизировал процесс синхронизации, итого 15+5-2=18). vm.dirty_background_bytes нас больше не интересует, потому что он синхронизатор уже запустился.
5 секунда: vm.dirty_bytes = 18
6 секунда: vm.dirty_bytes = 21
7 секунда: vm.dirty_bytes = 24
8 секунда: vm.dirty_bytes = 27
9 секунда: vm.dirty_bytes = 30
10 секунда: vm.dirty_bytes = 30 (vm.dirty_bytes уперся в вышеусловленное значение в 30 байт, больше места под dirty page у нас нет, поскольку синхронизирует записывает по 2 байта/с то мы упираемся в 2 байта/с, пока процесс не запишет все свои данные).
...
Энная секунда: (процесс записал все необходимые ему данные): vm.dirty_bytes = 28
n+1: vm.dirty_bytes = 26 (и т.п.).

То есть как видно dirty page позволяет нам "сгладить" небольший всплекс на запись, за счет того, что данные, которые нужно записать на диск будут временно храниться в памяти. Причем именно кратковременный всплекс, потому что на долговременном всплекске вы забиваете всю память, отведенную под dirty page и после этого скорость записи падает до скорости работы диска. Очевидно что технология полезная и иногда нужная, но все сильно зависит от ваших парентов нагрузки (именно по этому все совеют разные числа, у кого-то один вариант показывает себя лучше, у кого-то другой.) Увеличивая размер vm.dirty_bytes вы с одной стороны увеличиваете размер пика, который получиться сгладить, с другой увеличиваете объем ОЗУ которое займете под этот пик и время, которое понадобиться на то, что бы разгрести эту ОЗУ.
При этом я вижу что по дефолту в centos7 выставленны значения vm.dirty_background_ratio = 10 и vm.dirty_ratio = 30 (то есть 30% от всей доступной памяти можно занять под dirty page, запускать синхронизацию если зянято более 10%), vm.dirty_expire_centisecs = 3000 (сбрасывать на диск данные, которые находяться в dirty page больше 30 секунд вне зависимости от того, сколько в данный размер занято под dirty page) и vm.dirty_writeback_centisecs = 500 (синхронизатор должен просыпаться каждые 5 секунд для обработки данных, подподающих под vm.dirty_expire_centisecs).
На ubuntu (16.04 и 18.04) vm.dirty_ratio = 20, все остальные параметры точно такие-же как у centos.

Логика тут очень простая: под dirty page память не резервируется. Если она нужна и есть свободная память - она используется (максимум 30% или 20% от всей доступной). Причем доступная память, это не "всего установленно", это именно available память в выводе "free".
То есть мы получаем "некую автоматическую балансировку" системы по данному параметру в зависимости от "Total RAM - Used RAM", чем доступной памяти больше, тем больше может быть dirty page. Если собираетесь ограничить dirty page в 2-4-8 мегабайт, то хотя бы проведите набор тестов под вашей боевой нагрузкой (не синтетической, а именно боевой) и убедитесь что это хотя-бы не сделает хуже (не снизит производительность). Мой опыт говорит что на моих нагрузках большинство серверов чувствуют себя отлично со значениями по умолчанию.

А что в error.log'е nginx? Покажите весь кусок конфига nginx