А зачем? Подадут в суд? Ну по суду как-нибудь вернём.
Да установите себе уже панель, хоть бесплатную VestaCP или уж лучше FastPanel и ничего не надо делать и задавать уж такие вопросы.
Мобильная версия сайта, это вёрстка на CSS. Каким боком тут PHP?
Google уже писал, если я правильно помню, что все эти m.site.ru уйдут скоро в прошлое. Делать надо адаптивную вёрстку.
Увеличивать join кэш выборок не хочется, жуткий костыль.
Или отключать в мускуле резервируемости транзакций тоже не хочется.
Ну... скорость/сохранность данных. Тогда только SSD скоростные. Можно временные таблицы ещё в память перенести и дать большие лимиты им.
А, ясно, 9Тб памяти это супер железо! )))
У меня просто тоже есть один проект с тяжелой базой порядка 20 Гиг и товаров порядка 3млн.
Когда идет обновления тора из xml файла цен и характеристик, этот файл предоставляет производители.
Структура таблица Innodb.
То база просто парой замирает, нагрузка на проц 85-90%.
Где-то писалось на офф сайте мускула, что чем меньше значение query_cache_size, тем лучше.
Я его практически отключил на всех проектах.
Именно так. Я просто говорю не про сказки, как тут некоторые пишут, а просто про жизнь. Каждый день с таким сталкиваюсь, ничего особенно.
Выключать кэш надо, если много идёт записей в таблицы т.е. очень живой проект. Тогда просто кэш будет сильно тормозить т.к. много времени тратиться на его сброс, запись, проверку и т.д.
Конечно, нужно достаточно памяти на сервере, чтобы вся база легко уместилась в ней.
Если идёт загрузка данных, там просто надо устанавливать приличные лимиты для всяких tmp данных. Также очень сильно зависит как вообще идёт импорт. А то у cs-cart там при импорте в 1с, после каждого добавления товара идёт COUNT(*) в категорию... ппц... Приходится с этим жить.
Тогда это уже не БЕЗ перерыва. Вы себе заключённого в тюрячку хотите нанять на работу?
12 часов нахождения за ПК без перерыва? Это как вы себе представляете?
12 часов без перерыва за 15К? Самим то не смешно?
И тебе тех.поддержка и менеджер по продажам и ещё разнорабочий.
А что сделали на сервере где 3 млн товаров?
b2b решение какоето?
Да нет... вы просто масштабы некомпетентности не понимаете старых админов.
Там cs-cart, загрузка информации туда сюда идёт из 1С. У каждого товара по 5-15 характеристик.
Все таблицы в MyISAM и полностью дефолтные настройки mysql. Хотя нет... там размер кэша запросов установили:
query_cache_size=999999999999999999999999
Ну чисто, чтобы хватали. 9 ТБ памяти или 90 ТБ, не помню.
Загрузка 10 000 товаров могла идти сутки из-за того, что таблицы полностью блокировались. Сайт при этом ложился. И так каждый день изо дня в день. На вопросы админам, какого хера, ответы были такие:
- Ну наверное ДДОС идёт
- Ну наверное там что-то 1С делает
- Да само пройдёт ща
- 3 млн товаров, что вы ещё хотите?!
Я когда это всё слушал в течении 3-х месяцев, вообще был в шоке. Потом уже договорились о предоставлении доступов.
Процедуры были обычные, это настройка mysql/php под параметры сервера, БЕЗ выделения 9ТБ памяти, главное это перевод таблиц в InnoDB. И о чудо! Оказывается товары могут грузится в 10 раз быстрее и при этом сайт может не падать.
Корявые настройки сервера
Неправильный формат таблиц Mysql
Сломанные скрипты WP из-за косячных импортов товаров
Забытые настройки robots.txt
Без кэшевые перебирающие 30К товаров каждый раз скрипты
Какие нафиг KVM? Куда там NVMe? Люди берут 16 ядерную машину, с NVMe, 64 ГБ памяти, а у них opencart по 5 секунд грузится с базой в 200 МБ.
Это как, если гоночная машина не едет как надо, возможно надо прокладку поменять между рулём и сиденьем.
Месяц назад спас клиента жены, который хотел бизнес закрывать из-за криворуких админов, которые не могли настроить сервер под 3 млн. товаров, за 6 месяцев. И уверяли, что 128 ГБ памяти это мало для такого сайта.
