я добавил в .includes код. но поскольку он ниже того что в conf то не срабатывает
Это нормально, так как первый локейшен приоритетнее второго
Для начала изучить что такое try_files и как он работает.
Если вы хотите, чтобы несуществующая статика не падала на бэкенд, то делаете так
try_files $uri $uri/ =404;
но имейте ввиду, что если на сайте стоят плагины от криворуких разрабов, например всякие jpeg to webp converter, который вместо создания статики делает конвертацию через php, то можете столкнуться с проблемой, что внезапно статические файлы начнут отдавать 404 ошибку, потому что физически их не существует.
а если хотите сделать на уровне вынесенного conf, то надо делать отдельный локейшен с проверками.
Ну, у них переполнился /tmp, он может быть как отдельным диском/разделом, так и ramdisk, короче что угодно. Судя по файлу который пишет mysql - проблема с сохранением временных таблиц в mysql, видимо число файлов или размер файлов превысил допустимый /tmp размер, поэтому mysql не работает или работает нестабильно. При этом это никак не связано с диском вашей услуги - они могут быть физически находится на разных носителях.
Ну в общем-то ничего необычного - выбрали какой-то ноунейм, теперь страдаете, потому что они не смогли в мониторинг и не предусмотрели возможность переполнения /tmp. Это детские ошибки начинающих админов, кстати.
никакой ответственности, в соглашении с которым вы соглашаетесь указано что никакой ответственности хостер не несет, обычное дело вообще, просто выдаст чистый аккаунт, накинет там в качестве компенсации какой то период и скажет заливать сайт из бекапа (которого нет) по новой.
Вы сейчас про какие-то скамо-хостинги говорите, где никакой ответственности, кроме приема платежей, нет)
Хорошо, ну допустим клиент без бэкапов сидит и не делается. А если сбой оборудования, все данные пропали, а бэкапы битые? Это же материальная ответственность хостера.
Ну вообще вменяемый хостер проводит аудит целостности бэкапов, более того как правило процесс чаще автоматизированный. Тупо сверять что забэкапилось и насколько эти данные свежи, я хз, есть хостеры которые так не делают?
я беру цифры исходя из опыта на голом железе, где никакой настройки не производилось. откуда вы берете цифры я не знаю
умеет за счет pthreads, который из коробки никем не используется. да и для других задач он создан
условный битрикс/вордпресс как есть не будет использовать несколько ядер в моменте
+ не забываем про возможности воркеров, если используем апач и php-fpm, если nginx/иное
вот протестируйте и выложите сюда свои результаты. удивите общественность!)
Это все правильно для тяжолых запросах в небольшом количестве. А при огромном количестве запросов больше ядер выиграют и существенно.
да, но проиграют во времени ответа, если ничего не готовить как надо.
а бизнес скажет - зачем нам возможность обработки 1000 запросов, если мы отвечаем 5 секунд?!
мммм.... кто быстрее обслужит 1000 одновременных клиентов 16 ядре или 32 ядра? + MySQL тоже не умеет в мультипоток! Что про неё то не говорите?
p.s. нельзя так сравнивать.
Читаем начало топика: "Добрый вечер. Для php важна производительность одного ядра процессора?"
Причем тут mysql? Вопрос стоит именно про PHP. Он будет вашим бутылочным горлышком и замедлит всё приложение.
Быстрее обслужит != больше запросов обработает.
1000 одновременных клиентов 8 ядер 3.7ггц может не выдержать - да, в то время как 32 ядра их выдержат - да
Но каждый процесс этих клиентов будет обрабатываться, условно, 3 секунды, когда как 100 одновременных клиентов на 3.7ггц отработает каждый процесс за 1.5 секунды
Еще раз - php не multi thread language. Он не может 1 запрос обработать на 4 ядрах. Сможет, только если устроить ему fine tuning, в который добрая половина участников топика не сможет. Да и зачем? Есть более быстрые языки и интерпретаторы
