Если на уровне скриптов/запросов вопрос не решить, то ничего другого не остается кроме как дать ему делать что оно хочет так долго как хочет. Но постараться ограничить этот процесс обновления до пары ядер к примеру.
Как именно - надо смотреть предметно что конкретно там происходит. Если параллельно много скриптов долбят mysql - логично ограничить их количество. Сделать чтоб весь этот процесс проходил более однопоточно и оставались ненагруженные ядра для работы всего остального. Чисто железом, не меняя ничего программно, вопрос не решить - все равно будет все та же 100% загрузка, но просто другое количество времени. Можно лишь минимизировать ущерб (тормоза в других задачах помимо обновления) ограничив количество этих тяжелых потоков.
Конечно можно за ту же цену взять больше ядер/меньше частоту... и пусть даже пару часов обновления превратятся в час, но все остальное время ведь обычные запросы будут проходить медленней.
Есть процессоры 8-10-ядерные аналогичной 4+ггц частоты, но очевидно стоить это будет заметно дороже... и опять же, 2ч станут 1ч, но все равно моменты тормозов со 100% загрузкой никуда не уйдут.
Только более внимательного, не такого как здешний модератор.
Хотя он же и сам своего рода админ... 888 😎
Отключили же за атаку не НА, а ОТ.
Т.е. взлом или бэкдор, через который вы стали участником атаки на кого-то. Что делать? Лучше контролировать что там у вас происходит. Сложно что-либо советовать без понимания что там у вас и как, но как минимум надо посмотреть продолжаются ли попытки слать те пакеты. Если да, то чем - что-то "левое" запущено или тупо скрипты/бэкдоры на сайте. Смотреть все логи и т.д... короче лучше пользоваться shared хостингом, раз такие вопросы по форумам спрашиваете.
Так вот же где:
😏
На shared'е обычно сами бы перенесли и все сделали как положено.
Открываю сайт - он открывается, все норм, делаю изменения (по ФТП) ничего не вижу нового.
Захожу в админку ВП - там данные о старом сервере (версия пхп и т.п.).
В FTP клиенте может же быть вбит домен, а может сразу ip. Заливаем по фтп (именно на правильный новый ip) в корень какой-нть test.txt и открываем браузером - он наверняка не откроется, значит копаем почему браузер игнорирует hosts. Может vpn какой-то включен, может прокси, кто знает что там у вас. Самое быстрое - попробовать в другом браузере.
Полагаю у вас хром, т.к. firefox обычно адекватно реагирует на ctrl+f5 - сбрасывает свой dns кэш тоже.
В firefox еще желательно настроить очистку кэша после перезапуска, чтоб не маяться с подобными приколами - закрыл/открыл и браузер с чистого листа (почти, кроме куки) открывает все сайты как в первый раз.
Если url не менялся, то править обычно ничего не нужно. Да, абсолютные пути могут различаться между хостами, но обычно оно не влияет ни на что.
В данном конкретном случае у вас проблема чисто с браузером - он игнорирует записи в hosts временно (может нормально перегрузиться полностью нужно) или постоянно (какая-то хитрая настройка/фича/баг/плагин).
Если отвечать на прямой вопрос про единичный скрипт, выполняющийся 5сек (а не выдумывать условия типа ab -c 300 - долбежка 300 запросами одновременно по этому скрипту), то да почти без разницы будет это nginx или apache.
На скорость выполнения (повторяю, именно в этом случае - один запуск долгого 5-секундного скрипта) гораздо сильней влияет версия php, настройки php.ini (наличие opcache, обработка ошибок, модули подключенные и т.п.), скорость процессора (не мощность, не производительность, а именно single-thread скорость, зависящая от архитектуры/свежести ядер cpu и тактовой частоты), чем микро-разница между apache и nginx.
Также стоит учесть, что тот же apache с php может взаимодействовать ну очень по-разному (mod_php или cgi например). И то, что если выключить в apache поиск и выполнение .htaccess, то он не так уж радикально будет отставать от nginx (ну может кроме занимаемой памяти).
Плюс очень сильное влияние оказывает работа opcache в php. Поэтому без подробного сравнения всех конфигов нельзя ничего однозначно утверждать. Я вот даже когда делал тесты ниже столкнулся с загадкой почему под nginx/php-fpm скрипт выполнялся примерно на 100мс дольше... оказалось скрипт довольно древний и под php7.4 выдавал кучу deprecated сообщений в процессе выполнения. Когда заглушил эти ошибки в php.ini, результат пришел в норму.
Так что нельзя вот так безапеляционно заявлять, что nginx быстрей apache. Очень много нюансов и очень зависит от конкретных задач.
Итак:
Я с ходу не нашел на столько медленного и тяжелого скрипта, взял вот этот:
http://www.php-benchmark-script.com
Запускал у себя на домашнем роутере, а не где-то на сервере в инете, где постоянно бы влияли на результат соседи.
Он в это время совершенно ничего не делал и можно считать замер более-менее точным.
Проц E5-1630v4 с постоянной частотой 3.8-4.0ггц (не в спящем режиме каком-то).
Везде выставил одинаковую версию php 7.4 и одинаковые настройки php.ini и делаю 3 прохода подряд.
1) Запускаю bench.php из коммандной строки, т.е. под php-cli без включенного opcache в php.ini
Итого отправная точка: ~0.585сек рисует результат сам скрипт и около 0.59сек итого рисует нам time
2) Opcache в php-cli - это конечно не тоже самое, когда php запущен все время (php-fpm или mod_php например) и держит в памяти опкоды. Однако даже на время выполнения одного скрипта он может немного повлиять на результат.
Запускаю тоже самое, с opcache.enable_cli=1 в php.ini
Что изменилось: ~0.515сек (0.07сек выигрыш - 13%) и около 0.53сек итого по результату time
Т.е. однозначно, включение opcache даже в cli дает прирост. Какой именно - очень очень сильно зависит от самого скрипта и от их количества.
Естественно под веб-сервером, если php правильно настроен и запущен всегда с выделенным достаточным объемом памяти под opcache, и если скрипт будет не один, а к примеру wordpress с кучей php скриптов - результат вкл/выкл opcache может быть сильно более заметен.
И там еще будет влияние так называемого "холодного старта", т.е. в первый запуск будет чуть медленней, а потом уже чисто из opcache выполняться может заметно шустрей.
В нашем случае скрипт единичный и холодный старт практически нивелируется, но всеж перед проходом серией из 3х запросов я делаю перезапуск php-сервера.
3) nginx -> apache/mod_php
В итоге видим примерно те же 0.525-0.530сек по результату скачивания скрипта wget'ом с веб-сервера.
+/- в пределах погрешности, хотя и самую кроху шустрей, чем из под cli - ведь opcache тут уже работает полноценно как и должен.
Повторяю, на большем количестве скриптов результат был бы более заметен (не в пользу php-cli).
4) nginx -> php-fpm
Снова как видим все в пределах погрешности измерений ~0.525сек
Так какой правильный вывод? Именно в этом случае разницы не будет - хоть 0.5сек, хоть 5сек скрипт будет выполняться +/- одинаково не только из под apache или nginx, но даже из под php-cli (только если opcache.enable_cli будет выключен, то получится немного заметнее медленней).
Но! Не путаем это с реальными сайтами. В который раз повторюсь, там где не одиночный долгий скрипт, а много-много php файлов - там работа opcache будет куда более заметна. И в зависимости от нагрузки (количество запросов в секунду прилетающих на сайт) уже может вылезти различие между apache и nginx. Но это не касается обычных мелких сайтов, на которых и 1 запроса в секунду не приходит. Для них важней иметь пусть меньшее количество, но более высокочастотных ядер процессора. У сайтов же с большим траффиком все не так, не нужно их приплетать куда не следует. Да, там по итогу меньше нагрузка и больше скорость (суммарная на всех, а не у каждого отдельно взятого запроса) может получиться на 16-ядерном 2ггц процессоре, чем на 4-ядерном 4ггц. И какие-то минимальные (в обычных ситуациях) преимущества nginx могут также всплыть более ярко.
Еще раз - с уверенностью можно сказать, что один 5-секундный скрипт будет выполняться одинаково и под apache и под nginx. При условии конечно же одинаковых настроек php и если под apache совсем уж плохо все не настроено.
На 24 :)
Почему здесь спрашиваете? Кто тут может знать на сколько все безопасно у хостера этого? У него и спрашивайте... он конечно же ответит на 100% все супер.
А вообще подозрения правильные. Во-первых мы ж не знаем, может это один из вчера образовавшихся хостеров и запросто может оказаться тупым фишингом.
Но если проверенный (полно старых зарубежных хостеров/регистраторов с архаичными биллингами, которые никто не будет менять в ближайшую вечность и возмущаться бесполезно) и пользоваться нужно, то в любом случае конечно лучше карту где-попало не светить и использовать виртуальные карты. Которые пополнять перед самой оплатой и ничего на ней не держать лишнего.
Осенью делал 3 заказа у разных продавцов суммарно на немыслемые 4 бакса. Все были магическим образом объединены в один и да, доставлены новой почтой бесплатно.
Сперва все заказы отправляются по своим трекномерам, а потом они заменяются на один общий.
https://novaposhta.ua/tracking/international/cargo_number/aenm0003466678npi
Без понятия как это работает, но факт. Сколько там нынче минималка у новой почты для пересылки по стране, бакса два небось?... 🤔
Вам с вашими царскими $14 думаю переживать вообще не стоит. Доставят.
И что в итоге вам известно о том, кому заплатили?
На все это нужен паспорт... который будет чуть позже.
Тут даже нет вопросов к пацану, а скорей вопрос адекватности его "клиентов". Такие и на авито переводят непойми кому на карту и потом ждут с моря погоды.
Т.е. спрашивать по каким-то форумам, давать кому-то доступы - это нормально.
А просто обратиться к хостеру чтоб тот посмотрел что не так или просто сделал дамп - что-то из разряда фантастики?
Это первое что стоило бы сделать.
Второе:
phpmyadmin у вас от панельки какой-то? Я бы скачал последнюю версию и закинул на сайт. Т.к. а) маловероятно, но какой-то баг в phpmyadmin б) вы скорей всего увидите в логах ошибки, если такие там имеются (лога phpmyadmin от панели скорей всего вам не увидеть). Запросто может просто оказаться какой-то default параметр в php или специально зачем-то сильно урезанный.
Дальше. Кроме phpmyadmin есть же другие инструменты, например:
https://www.adminer.org/#download
Также, если даже нет ssh, то можно попытаться из под php запустить mysqldump и может он сделает дамп правильно.
Кроме вас и вашего хостера никто тут не видит что именно и кто запрашивал в моменты этих всплесков.
Если вы не знаете куда смотреть, просите того, кто должен знать - хостера.
А так, конечно же первым делом access логи вебсервера.
Во-первых чтоб убедиться, что действительно дело в 135.131.185.35.bc.googleusercontent.com, а не чем-то/ком-то еще.
Во-вторых смотрите что конкретно оно там с вас скачивает такое объемное. Может фото-видео тяжелое.
И что вообще за 135.131.185.35.bc.googleusercontent.com - за ним ведь скрываться может любой ip, даже совершенно не связанный с гуглом. Если действительно что-то левое - просто бан (любым способом) и все, зачем ходить по каким-то форумам, спрашивать кого-то кто понятия не имеет что у вас там происходит...
