Я всё равно не понял :( У меня Centos 7Вот конкретно эти строки надо в файл конфига где-то сверху добавить?
Зато в связке с возможностью в isp юзать opendkim сработал способ, предложенный LEOnidUKG Спасибо!
Если не поняли, ну что ж тут поделать.
Я объяснил более развернуто.
Вот это где и как прописать? Что это за команды?
Это файл текстовый, находится в директории exim.
У каждой системы своя директория конфигов exim.
В файле прописана структура домен: ключ.
у меня почти белый интернет магазин, просто для перестраховки. чтобы не лазили такие люди по сайту. как это сделать?
Если белый, то тогда не парьтесь!
Не спасет эта сомнительная блокировка, только ухудшит показатели посещаемости!
я использую панель управления fastpanel для сайтов в режиме cgi, как можно внести эти адреса и заблокировать в моем случае?
Вносить в ручную в конфиг. nginx или apache.
Никчему хорошему эта затея не приведет, ресурс ваш все равно заблокирует хоть как не крути!
Прослушиваемый порт на сервере может только на одном сервисе.
Если тебе нужно что бы nginx прослушивал порт 443, то настрой сам nginx под твои нужны, а apache повесь на 8080 порт к примеру.
Ну... скорость/сохранность данных. Тогда только SSD скоростные. Можно временные таблицы ещё в память перенести и дать большие лимиты им.
Это все есть.
база на диски nvm intel dc p4510 - 1Tb - хороший диск, пул innodb сделал чуть на 15% больше чем сама база.
Да и кэш открытых таблиц базу также в памяти и при этом все равно обновления товара проходит медленно .
Сам сайт в шататном режиме работает хорошо, быстро.
Но вот обновление.
Подумываю что битые индексы таблиц.
Именно так. Я просто говорю не про сказки, как тут некоторые пишут, а просто про жизнь. Каждый день с таким сталкиваюсь, ничего особенно.
Выключать кэш надо, если много идёт записей в таблицы т.е. очень живой проект. Тогда просто кэш будет сильно тормозить т.к. много времени тратиться на его сброс, запись, проверку и т.д.
Конечно, нужно достаточно памяти на сервере, чтобы вся база легко уместилась в ней.
Если идёт загрузка данных, там просто надо устанавливать приличные лимиты для всяких tmp данных. Также очень сильно зависит как вообще идёт импорт. А то у cs-cart там при импорте в 1с, после каждого добавления товара идёт COUNT(*) в категорию... ппц... Приходится с этим жить.
Увеличивать join кэш выборок не хочется, жуткий костыль.
Или отключать в мускуле резервируемости транзакций тоже не хочется.
Да нет... вы просто масштабы некомпетентности не понимаете старых админов.
Там cs-cart, загрузка информации туда сюда идёт из 1С. У каждого товара по 5-15 характеристик.
Все таблицы в MyISAM и полностью дефолтные настройки mysql. Хотя нет... там размер кэша запросов установили:
query_cache_size=999999999999999999999999
Ну чисто, чтобы хватали. 9 ТБ памяти или 90 ТБ, не помню.
Загрузка 10 000 товаров могла идти сутки из-за того, что таблицы полностью блокировались. Сайт при этом ложился. И так каждый день изо дня в день. На вопросы админам, какого хера, ответы были такие:
- Ну наверное ДДОС идёт
- Ну наверное там что-то 1С делает
- Да само пройдёт ща
- 3 млн товаров, что вы ещё хотите?!
Я когда это всё слушал в течении 3-х месяцев, вообще был в шоке. Потом уже договорились о предоставлении доступов.
Процедуры были обычные, это настройка mysql/php под параметры сервера, БЕЗ выделения 9ТБ памяти, главное это перевод таблиц в InnoDB. И о чудо! Оказывается товары могут грузится в 10 раз быстрее и при этом сайт может не падать.
А, ясно, 9Тб памяти это супер железо! )))
У меня просто тоже есть один проект с тяжелой базой порядка 20 Гиг и товаров порядка 3млн.
Когда идет обновления тора из xml файла цен и характеристик, этот файл предоставляет производители.
Структура таблица Innodb.
То база просто парой замирает, нагрузка на проц 85-90%.
Где-то писалось на офф сайте мускула, что чем меньше значение query_cache_size, тем лучше.
Я его практически отключил на всех проектах.
Корявые настройки сервера
Неправильный формат таблиц Mysql
Сломанные скрипты WP из-за косячных импортов товаров
Забытые настройки robots.txt
Без кэшевые перебирающие 30К товаров каждый раз скрипты
Какие нафиг KVM? Куда там NVMe? Люди берут 16 ядерную машину, с NVMe, 64 ГБ памяти, а у них opencart по 5 секунд грузится с базой в 200 МБ.
Это как, если гоночная машина не едет как надо, возможно надо прокладку поменять между рулём и сиденьем.
Месяц назад спас клиента жены, который хотел бизнес закрывать из-за криворуких админов, которые не могли настроить сервер под 3 млн. товаров, за 6 месяцев. И уверяли, что 128 ГБ памяти это мало для такого сайта.
А что сделали на сервере где 3 млн товаров?
b2b решение какоето?
Пока нашел решение заменить Cache::SharedMemoryCache на Cache::FileCache.
В самом начале файла заменяем две строчки.
/usr/local/share/munin/plugins/mysql_
меняем
BEGIN { eval { require Cache::SharedMemoryCache; };
На
BEGIN { eval 'require Cache::FileCache';
my $shared_memory_cache ;if ($has_cache){ $shared_memory_cache = Cache::SharedMemoryCache->new(\%cache_options)
my $shared_memory_cache ;if ($has_cache){ $shared_memory_cache = Cache::FileCache->new(\%cache_options)
То что нужно заменить выделил жирным.
Почему с Cache::SharedMemoryCach не работает, хз.
