Сегодня нам пишут, что в ПрестаШопе админка повесилась: при переходах между страницами в админ.панели PrestaShop начали появляться провалы во времени, задержки около 15-20 сек.
Выглядит проблема примерно так:
[03:51:17] Anon: Добрый день, очень медленно работает админка сайтта, это невыносимо просто ждаь. Надо бы как-то исправить
[xx:05:38] itMag: Здравствуйте, а по какой именно ссылке, в какой части админ.панели?
[xx:06:57] Anon: вся админ панель. о входа и так далее
[xx:07:11] Anon: от момента входа и любая другая его страница
[xx:10:27] itMag: с фронтом сайта как я вижу проблем нет?
[xx:10:45] Anon: все верно, фронт летает хорошо
[xx:31:39] itMag: да, задержка между переходами около 10-20 сек, может быть из-за ожидания подключения к мёртвым зеркалам/серверам обновлений или типа того, - когда примерно это началось?
[xx:32:12] Anon: это началось довольно давно, но усугублось мне кажется несколько недель назад
[xx:32:51] itMag: довольно давно - это примерно когда?
[xx:33:35] Anon: это прям очень давно. я не вспомню, больше чем пол года назад
[xx:37:50] itMag: но, внутренности сервера говорят (прога тор), что в момент задержек перехода по ссылкам админ.панели - нагрузки на сервер почти 0, это точняк где-то какой-то модуль выжидает подключения к мёртвому домену/серверу ... обновлений и т.п... осталось только выяснить как его звать
[xx:40:07] Anon: что касательно админки я сам точно ничего не ставл уже давно. да и вообще сам ничего не ставил и в настройках не лазил
[xx:44:25] itMag: ок, то бывает, модули устаревают, отсыхают/исчезают их сервера обновлений.., тогда так и происходит, - но проблема с поиском таких модулей в том, что подключаются они ж к сети обычно с помощью РНР функций, а не внешних скриптов вставленных в браузер...
После отключения авто-обновления модулей, проблема с тормозами админки продолжала быть, - проблема оказалась не в модулях. Но чтобы лишний раз в том убедится был включен дэбаг в /config/defines.inc.php
define('_PS_DEBUG_PROFILING_', true);
В результатах которого по задержке лидировал initContent (10669 ms, 9-ку перевернуть и получилось бы 10666):
Time Cumulated Time Memory Usage Memory Peak Usage ... initContent 10669 ms 10875 ms 21.82 Mb 40.28 Mb initFooter 1 ms 10876 ms 0.04 Mb 40.28 Mb display 26 ms 10903 ms 1.74 Mb 42.34 Mb
Однако по основным процессам таким, как Module и/или SQL Query существенных задержек в обработке данных не обнаружено.
Пока неизвестно по-каким причинам, но даже при входе в админку перед вводом логина и пароля, PrestaShop back office упорно пытается подключатся к своей родной гавани по доменным веб-адресам и это поведение никак не связано с модулями:
- prestashop.com
- api.prestashop.com
- addons.prestashop.com
У каждого из перечисленных есть IPv6:
# nslookup prestashop.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: prestashop.com Address: 104.16.210.130 Name: prestashop.com Address: 104.16.211.130 Name: prestashop.com Address: 2606:4700::6810:d282 Name: prestashop.com Address: 2606:4700::6810:d382 # nslookup api.prestashop.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: api.prestashop.com Address: 104.16.210.130 Name: api.prestashop.com Address: 104.16.211.130 Name: api.prestashop.com Address: 2606:4700::6810:d382 Name: api.prestashop.com Address: 2606:4700::6810:d282 # nslookup addons.prestashop.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: addons.prestashop.com Address: 104.16.211.130 Name: addons.prestashop.com Address: 104.16.210.130 Name: addons.prestashop.com Address: 2606:4700::6810:d282 Name: addons.prestashop.com Address: 2606:4700::6810:d382
Пропинговав которые изнутри сервера, на том оно всё и позалипало:
# ping prestashop.com PING6(56=40+8+8 bytes) 2a06:хххх:bbbb:cccc:6f5a:fa6e:19b2:0 --> 2606:4700::6810:d282 ...HUNG (ЗАВИСЛО, ЗАЛИПЛО)... ^C --- prestashop.com ping statistics --- 66 packets transmitted, 0 packets received, 100.0% packet loss # ping api.prestashop.com PING6(56=40+8+8 bytes) 2a06:хххх:bbbb:cccc:6f5a:fa6e:19b2:0 --> 2606:4700::6810:d382 ...LONG TIMEWAIT WITHOUT RESULT... ^C --- api.prestashop.com ping statistics --- 66 packets transmitted, 0 packets received, 100.0% packet loss # ping addons.prestashop.com PING6(56=40+8+8 bytes) 2a06:хххх:bbbb:cccc:6f5a:fa6e:19b2:0 --> 2606:4700::6810:d382 ...HUNG (ЗАВИСЛО, ЗАЛИПЛО)... ^C --- addons.prestashop.com ping statistics --- 66 packets transmitted, 0 packets received, 100.0% packet loss
И вот оно (PrestaShop) как бы чует, что IPv6 сеть вроде как бы где-то должна быть (в смысле в операционной системе) и по какому-то хотенью/веленью начинает предпочитать IPv6 адрес, но по факту IPv6 сети как бы там и нет (ака их там нет
) - 100.0% packet loss.
Дело стало прояснятся.., - появились проблемы с IPv6...
Проблемы с сетевым подключением
Сеть упала, снова... Если я побегу быстро,
то смогу спастись до того, как они заметят.Перед тем, как они убьют меня...
Тут сразу кроме IPv6 вспомнились ещё и древнейшие проблемы с IPv4 подключением на этом серванте, на хостинге если точнее...
ОС FreeBSD 12, чистая установка, аппаратная KVM-виртуализация и шустро всё арбайтен, но по каким-то причинам регулярно отваливается IPv4 маршрут по-умолчанию (default route) и кино заканчивается, а для восстановления default route приходилось залазить в сервант через веб-VNC-консоль хостинг-провайдера.
Такая херня происходила случайным образом (рандомно), -
- по 5-10 и более раз в день;
- 1-2 раза каждый день;
- 2-3 раза в неделю;
- могло иногда неделями и стабильно без сбоев работать.
Складывалось впечатление, что кто-то там в серверной из сетевых проводов замутил себе гамак и зависает в нём с пивом и тёлками, а когда у них там начинается... джага-джага-шнэля-шнэля-ибэн-ибэн.., то на сервере возникают перебои с сетевым подключением.
К примерно похожему мнению склоняются и другие юзеры подобного недуга:
Default route not surviving reboot and randomly disappearing | The FreeBSD Forums
There could be several reasons. The first could be that the card is faulty and it's just limping along until it completely dies. Another reason could be a bad cable causing the connection to to be down intermittently. It could also be the port of the switch it is connected to...
После очередной пропажи default route, IPv4 сеть поднимал и прописывал к ней default route небольшой баш-скрипт, который мы сделали быстрее чем заняло бы общение с ТП. Тот скрипт скачивал веб-страницу гугла во временный файл, который удалялся в конце работы скрипта, а если скачивание не удавалось, то выполнялся набор команд восстанавливающих сетевое IPv4 соединение и отправлялось письмо на эл.почту с отчётом о происшествии.
Но.., в один "прекрасный" день эл.почту стало просто засыпать такими отчётами и уж тут пришлось по-колено закатав рукава, да-да... ошибки тута быть никак нимагёт ... именно по-колено значит закатав рукава.., - пришлось начинать дебаты с ТП...
ТП традиционно говорит, что: а у нас всё в шоколаде, лимонаде, мармеладе...
- и кто бы сомневался!
В этот момент обнаружились ещё какие-то проблемы с IPv6 ресолвом, видимо именно с этого момента с IPv6 что-то пошло не так на этом хостинге.., но IPv4 работало и вероятно получалось наполовину ложное срабатывание скрипта восстановления сети (вариантов туева хуча).
Скрипт был временно отключен, сеть IPv4 была рабочая, и тут.., Пи...АСЫ из ТП, БЕЗ КАКОГО-ЛИБО ПРЕДУПРЕЖДЕНИЯ, переключают сервант на virtio и говорят: Теперь у вас усё будит зашибись работать!
, - а сеть же тем временем вовсе наглухо пропала потому, что под virtio нужна совсем другая конфигурация с подгрузкой драйверов и совсем иными сетевыми конфигами!
АХ ВЫ Ж Пи...АСЫ!!! Верните всё как было взад!
- ведь тогда мы были в пути и с телефона на коленке да ещё и в движении.., когда штормит.., ну поняли думаю, да..?! Почти шо сцать против ветра... Так прошло около часа, но воз оставался и ныне там...
Ну.., собрались.., с коленки начали ж значит virtio конфигурировать... Вот думаю.., щас всё сделаем и те Пи...АСЫ, вернут, как мы же и просили снова всё взад, как было.., - вот посмеёмся то...
Вероятно с тех пор IPv6 почти совсем то и отпало.
Что примечательно, что до того момента IPv6 работало на адресе 2a06:хххх:bbbb:cccc:6f5a:fa6e:19b2:0 и virtio под него тогда был сконфигурирован правильно, но по-какой-то причине работать оно (паскуда) перестало.
Сегодня безуспешно пробовали поднять IPv6 на адресах:
- 2a06:хххх:bbbb:cccc:6f5a:fa6e:19b2:1
- 2a06:хххх:bbbb:cccc:6f5a:fa6e:19b2:2
Уже думалось, что IPv6 сдохло на этом хостинге.
Даже создали IPv6 Tunnel от Hurricane Electric:
IPv6 у хостера таки (падлюка) заработало только после того, как:
- мы снова дое..лись к ТП;
- удалили все правила фаервола, отключили, включили, заново пересоздали правила.
Но заработало оно уже на адресе 2a06:хххх:bbbb:cccc:6f5a:fa6e:19b2:69, - кроме адреса нихера иного в конфигах то и не менялось!
Может, то:
- или вкл/выкл, пересоздание правил, фаервола помогло?
- или хостинг-провайдеру нужен новый сисьадмин?
Истинные причины сетевого недуга доподлинно установить не представляется возможным, но IPv6 пока снова работает, бэк-офис Преста(Господи прости)Шопа больше не тормозит.
Ещё как вариант, во избежание такого лютого геморроя с IPv6, доменные адреса можно заглушить в файле /etc/hosts или прописать там реальные IPv4 адреса этих доменов:
127.0.0.1 prestashop.com 127.0.0.1 api.prestashop.com 127.0.0.1 addons.prestashop.com
Другие варианты по-ссылкам:
- Prestashop slow back-office (initContent : 12000ms) - Stack Overflow
- prestashop 1.6 back office slow initContent at DuckDuckGo
