Я же сказал, что это мое личное мнение. У вас свой опыт, у меня свой :) С самого начала эры ssd были в пользовании (и домашнем и в серверах нескольких своих) десятки разных дисков, некоторые даже лет по 10 проработали. Но все в итоге ушли на вторичку по причине устаревания морального, ни один не сломался. Дублировать даже мысли не возникало никогда. Разве что в RAID-0 для еще большей скорости, но только дома - одно время несколько лет в паре проработали X25-E, а сейчас также optane 32gb мелкие m.2. Понятно что в production серверах так не стоит делать, хотя уверен что тоже молгло бы работать без проблем годами. Сейчас в серверах по 1шт на SLC, MLC и Optane работают уже года 2 точно. Допускаю конечно что у вас просто количество серверов на порядки больше и потому вероятность отказа выше. Но всеж, уж простите, но продолжу считать что отказ диска - это НЕ норма. Просто сам диск надо выбирать с умом (среди DC также полно ширпотреба), плюс не насиловать его лишний раз ненужной работой (настройка ос/фс и остального софта), не перегревать (доп. обдув) и ничего ему не станется.
P4610 хоть и DC, но всеж на TLC... Опять же, имхо, но считаю что надежные диски закончились на P3700. Дальше пошло барахло. Ну кроме конечно оптанов P4800X и т.п.
Чисто имхо:
Если диски в raid-1 у хостера, то это наоборот звоночек, что скорей всего диски дешман и переживают что в любой момент может какой-то отказать. Нормальным дискам никакие raid'ы не нужны.
Куча дисков на одном сервере - также звоночек, что клиентов на этом сервере огромное количество. И скорей будет нехватка по cpu, чем по диску.
Хотя конечно если речь про vps, где всего 8 клиентов и каждому персонально выделено по одному из этих 8 дисков, то это совсем другой разговор.
Ну и главный подвох в том что сам факт NVMe диска еще не делает его каким-то супербыстрым применительно к хостингу. TLC/QLC NVMe может оказаться хуже (по работе с мелкими файлами, по записи), чем SATA на MLC.
"Вы кто" - подозреваю имеется в виду - где вы находитесь. Как минимум страна регистрации, где платите налоги и под чьими законами работаете. И адрес офиса, "куда в случае не очень аккуратного ответа со стороны техподдержки я могу заявиться и принудить всё-таки отработать замечание" (С) соседняя тема :)
На основном сайте у вас ничего нет, никакого "о нас" и выглядит на первый взгляд как мутный школохост.
Хоть это и не ваш случай конечно.
"Вы кто" можно разве что тут откопать:
https://cp.inferno.name/knowledgebase/20/Rekviziti-kompanii.html
Но кто этим будет заниматься?... Стоило бы по-ближе эту информацию на сайте разместить для избежания подобных недоразумений.
На shared'ах многих он есть. Полноценный имелось в виду через putty, а не "веб-версии".
Врядли имелся в виду root доступ. SSH нужен скорей всего ради git'а, ну и может распаковать архив или типа того. А не устанавливать что-то, конфиги править.
Если человек просто хочет добавить сайт и чтоб он просто работал, то зачем ему нужно вот это вот все?
Нормально все настроить далеко не каждый сможет, на это нужно не мало знаний и времени. Если вам это легко, то не значит что также всем.
Да и после, администрирование (следить за этим сервером чтоб все работало и решать возникающие проблемы/вопросы) - это лишняя работа, которая опять же требует времени и знаний.
Просто накинуть панельку - это вообще не то. Однозначно будут возникать сложности и вопросы. Shared хостинг для того и есть, чтоб за вас кто-то этим всем занимался. А вы лишь будете заниматься спокойно своими сайтами, не отвлекаясь на лишнее.
Не подкладывайте человеку свинью 😎
В .htaccess:
RedirectMatch ^/$ /main/
(должен быть apache с модулем mod_alias)
или:
RewriteEngine onRewriteRule ^$ /main/ [L,R=301]если именно 301й нужен
Ну или на php можно тоже, если сделать сперва проверку мол если URI=/, то редирект.
Смотря что (htaccess или index.php) у вас там может автоматом перезаписаться при обновлении например.
Какие процессы? Если кэширование не использовать, т.е. страницы каждый раз генерируются заново - выполняется куча скриптов и запросов к базе.
Для того и кэш-плагины, чтоб не делать одну и ту же дурную работу.
За счет чего по-вашему это можно ускорить? Только либо уменьшением количества работы, либо увеличением скорости работы (железо). По-сути и все.
Из расширений php лишь opcache дает заметный результат. И то, по-сути это ведь все то же кэширование, которого вы по какой-то причине избегаете :)
Самое простое и правильное это не делать лишнюю работу вообще, т.е. страница сгенерировалась, сохранилась и дальше какое-то время отдается готовая.
Пример того, о чем говорю - opencart.
В папке storage есть logs и там можно найти много того, чего не будет в error.log веб-сервера.
Но кто знает что там у вас...
Ну мы же не знали таких подробностей... я сразу предположил, что страницы какие-то внутренние, на которые редко натыкаются только яндексботы всякие, а не люди.
Но если главная, то да, кто-нибудь бы уже заметил.
Вы всеж в логах посмотрите, много ли там этих 500 ошибок на главной. И у кого они возникают, только у яндексбота или у других тоже?
Надо вникать как конкретно сделан сайт, правит ли cms (cms ли вообще?) например error_reporting или еще как-то перехватывает ошибки.
Т.к. пока складывается впечатление, что запрашивается например главная, она генерируется, возникает ошибка, она перехвачивается (в error.log ничего не попадает) и страница продолжает создаваться и отдается клиенту. Т.е. он видит страницу, ну а 200 был ответ или 500 в браузере не видно. Страница и страница...
Что можно попытаться. Если "цивильно" запретить cms перехват ошибок не получится (включить какой-то debug mode например), то можно попробовать на уровне php запретить например функцию error_reporting для начала - добавить disable_functions=error_reporting в php.ini
Ну и глянуть среди файлов/папок самого сайта, нет ли там нигде никаких log[что-то там]. Может всеж cms ваша записывает все эти происшествия, вы просто не замечаете их. И там уже наверняка будут подробности, когда и в чем конкретно возникают ошибки.
Вам дали правильное направление куда рыть... что еще вы хотите услышать?
Никто здесь ни малейшего представления не имеет что у вас там за сайт, не имеет никаких исходных данных.
Ваши десятки человек запросто могут просто никогда не запрашивать страниц, на которые заходит яндекс и получает error 500. Простейший пример - sitemap. Зачем в принципе их людям запрашивать, вот ботам - да.
Никто не знает что в вашем понимании "происшествие", предположу что вы имеете в виду лог ошибок веб-сервера.
Но запросто может быть, что cms перехватывает ошибки (возможно даже ведет где-то свои логи) и в error.log ничего не попадет, хотя ответ 500 клиенту уйдет если была всеж ошибка.
Короче...
Все логи.
Открываете access log и смотрите, там обычно после uri и версии http идет код ответа и потом размер отправленных данных в байтах. Если конечно как-то иначе custom'но не настроено логирование.
И именно тут ищите свои 500 ошибки, а не в логе ошибок.
Наверняка найдете. После чего пробуйте вручную открыть ту страницу и что там будет в ответ приходить смотрите и в браузере и в логе том же.
Т.к. есть еще вероятность, что страница отдается нормально, но по какой-то причине в заголовках отдается ответ 500, а не 200.
Вариантов возможных много, но первым делом ваша задача найти конкретные страницы с ответом 500 в ваших логах.
