Error receiving response header lsphp is killed

How to troubleshoot the error «Failed to process response headers»

Question & Answer

Question

Cause

In almost every event, this error is caused by a connection failure.
The error is correct, the service did not receive any response headers or data. The key to help confirm this is to increase the log level to debug. This allows you to see the network debug errors around the context of the service error.

Answer

• A slow response that causes the connection to timeout before receiving the response
• A failed connection attempt due to a closed persistent connection or some other connection issue that prevents the WebSphere® DataPower device® from connecting to the backend. For example, a reused connection would be attempted and found to already be closed out by something outside of DataPower®.
  An example of this is explained here:
  http://www-01.ibm.com/support/docview.wss?uid=swg21417934&wv=1

There are a broad range of network errors that can trigger this to error. A packet trace is the key to capture the problem and confirm what type of failure is the cause. A log with event subscription of «all» «debug» will also help correlate and confirm the packet trace data.

Источник

Fix Nginx 104: Connection Reset By Peer While Reading Response Header From Upstream

Nginx 502 is an uncommon error that causes due to issue with your server Nginx and PHP-FastCGI. If you notice any Nginx 502 error it is better to check the Nginx log.

When you are investigating the Nginx error logs, you can see that the “recv() failed (104: Connection reset by peer) while reading response header from upstream,” error. This also results in a “no live upstreams while connecting to upstream” error. When I’m checking my WordPress site logs I saw that several times appeared that error log. This is an issue with the Nginx and PHP-FPM configurations. Can easily fix it in just a few steps.

There are mainly three different reasons for Nginx Connection reset by peer.

• Nginx and PHP-FPM communication error.
• PHP-FPM is timing out quickly.
• PHP-FPM is not running.

In order to fix 104: Connection reset by peer while reading response header from upstream issue, you should have access to modify the PHP and Nginx configuration files. If you are on shared hosting or a managed hosting package, you can ask your hosting partner to correct that configuration file.

Table of Contents

How to Fix Connection Reset By Peer While Reading Response Header From Upstream.

If you can see continuous connection reset by peer error your visitors may receive “502 Bad Gateway” errors. To correct this Nginx error you must set Nginx keepalive_requests and PHP-FPM pm.max_requests equal value. If these two values are not equal then the Nginx or PHP-FPM end up closing the connection. This is an issue caused by server configuration mismatch, you can fix it by like our Logrotate issue guide.

Change Nginx keepalive_requests.

• Open the nginx.conf configuration file with sudo privileges.

Copy

• Change keepalive_requests as per your need. Don’t use too high keepalive_requests, it can cause excessive memory usage.

• Save the configuration file.

Change PHP-FPM www.conf

• Open the www.conf file with sudo privilege.

Copy

• In “pm.max_requests” enter the same value you set on “keepalive_requests” in the Nginx conf file.

• Save the configuration file.
• Restart the Nginx and PHP-FPM by running the following command line.

Check PHP permission for session.save_path.

In some situations, your PHP is not able to write the season file. This will generate Nginx 502 connection reset by peer while reading response header from upstream.

There can be several reasons for PHP is not able to write the season file. It can be bad permissions, bad directory ownership, or even bad user/group.

• First check where your PHP session.save_path is. Some situations it is “/var/lib/php/sessions” or “/var/lib/php/session“
• Open your system php.ini file and search for “session.save_path“.
• Then you can see your system PHP session.save_path.
• Run the following command in your SSH terminal to fix the permission issue. In this example my LEMP stack php session.save_path is “/var/lib/php/session“

Copy

• Then restart php.

Change FastCGI Timeouts.

Another solution is to change the Nginx Fast-CGI timeouts. Default FastCGI timeout is the 60s. Your application may require higher than the 60s to run, therefore it is better to change the following timeouts to prevent Nginx 502 bad gateway error.

• Open the nginx configuration file. Generally it is “/etc/nginx/nginx.conf“.
• Change add the following timeout values to your nginx.conf.
  • • fastcgi_read_timeout 300;
    • fastcgi_send_timeout 300;
    • fastcgi_connect_timeout 300;
• Save the changes and restart nginx.

Increase opcache memory limit.

If your system PHP uses opcache if the opcache memory gets filled, it will show connection reset by peer while reading response header from upstream. The simple solution is to increase the opcache memory limit.

Источник

Можно ли пересоздать экскизы через консоль?

Нужно создать все экскизы через консоль. Товаров много, через вебинтерфейс не получается. Есть ли команда в WA для этого?

60 ответов

Насколько я знаю — нет. Но можно сделать свой cli-экшн для этого.

А почему через веб не получается?
Вроде в лимиты никакие упираться не должно — там longaction-контроллер работает. Может хоть сутки пахать.

Или вообще поставить в настройках галку генерации эскизов по требованию и не заморачиваться с отдельной генерацией для всех товаров.

Не знаю. У меня не получается. Через пять минут обрубается. Из-за этого пришлось разрешить создание эскизов «на лету», хотя оно мне никаким боком не нужно.

Имхо — однозначный косяк хостера. Вы б их поподробнее расспросили, в чем причина, потому как во время выполнения скрипта никак не должно упираться. Ну или оно там совсем маленькое, секунд 10. Небезызвестный псевдохостинг beget страдает таким. Тоже говорят что мол слишком долго скрипт работает, но если их прижать вилами к стене — раскалываются что косяк на их стороне, но при этом все равно ничего сделать не могут.

На скрипты стоит 30 секунд, стандартно. Я с ними связывался. Они сказали, что у них такая настройка — таймаут для nginx 300 секунд.

Скорее всего лукавят. Ну таймаут у них такой и стоит наверняка, но только скрипт там не выполняется 300 секунд. Он дергается много раз, и каждый раз его выполнение укладывается в какие-то разумные значения. По крайней мере с таймаутом в 60 секунд процесс регенерации эскизов проходит долго (2-3 часа), но нормально и корректно в магазине с 12-15 тыс. товаров. Поэтому надо либо бодаться с ними, оперируя правильной терминологией, или смириться и забить. Кстати, а импорт/экспорт нормально отрабатывают? С высокой долей вероятности там должно проявляться нечто подобное,если, к примеру, десяток тысяч товаров с характеристиками импортировать.

Импортом-экспортом не пользуюсь. Отчеты некоторые не работают.

После долгой переписки с хостерами вот их ответ: «Любой процесс на хостинга завершается через 5 минут, это глобальное ограничение и его нельзя обойти

На сервере запускается основной процесс php и он инициализирует запуск дочерних(которые обрабатывают запросы). Вот как раз основной процесс каждые 5 минут убивается системой»

Даже не представляю что им сказать на это.

Уф. Намучился, но нашел-таки очень прозрачный и понятный комментарий Леонида Вакуленко, в котором он рассказывает принцип действия всех этих дел. Как видите, даже если основной процесс убит — это не останавливает весь механизм. Поэтому, то что вы получаете 50x — это проблема хостера, а не движка.

P.S. Ссылка кривовато открывается, но речь о комментарии от 2 июля 2015 07:56

Павел, спасибо огромное. Закинул им, пусть потеют. )) Хотя думаю, что ничего не будут делать.

Я тут заметил кое-что. После очередной попытки пересоздать эскизы и получения через пресловутые 5 минут ошибки 504, заглянул в логи сервера. Там одна за другой продолжают идти записи типа:

POST /webasyst/shop/?module=settings&action=imagesRegenerate HTTP/1.0″ 200 42 «https://kosmetichka.com.ua/webasyst/shop/?action=settings» «Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.72 Safari/537.36

Я правильно понимаю — это продолжется создание эскизов как бы в фоне, несмотря на ошибку 504 от nginx?

Совершенно верно! Процесс идет, а вот какого рожна хостер вам в браузер 50x отдает — вот ответ на этот вопрос и надо у них отжать, потому как нет на то никаких видимых причин.

Кстати. У меня вопрос -) А где вы видите эту 504-ю ошибку?
Прямо в браузере на странице пересоздания эскизов?

Ведь по логике, бэкенд этого экшена должен продолжать работать несмотря ни на какие ошибки и просто посылать каждые 30 секунд запросы на сервер чтобы продолжить работу.

Да, прямо в браузере. Только вместо страницы пересоздания эскизов.

Возможно, он что-то и должен. Я выше показывал строки из логов. Но все же до конца скрипт не отрабатывает, половины картинок нет.

У них стоит некий глобальный таймаут на выполнение любого действия 300 секунд.

Насколько я понимаю, речь идет о настройках nginx. Не max_execution_time, а что-то типа этого:

Т.е. все рубится через 300 секунд.

Чушь. Что рубится-то? Процесс? Ну пусть, еще один запустится. У вас на экране открыта страница, на которой JS каждые n секунд обращается по некоему URL. И вдруг ни с того ни с сего 504. С чего вдруг? Вы посмотрите в консоли — когда вы запускаете процесс страница уже загружена. Так? Так. Потом JS дергает определенный URL периодически, получает ответ, снова дергает, опять получает ответ, снова ждет, и так до конца процесса. Что тут выполняется 300 секунд, что в браузере 504 вываливается? Ну ерунда ж.

Нет, ведь ни я, ни вы, ни кто-либо из WA не против этих героев, которые мужественно толпой набрасываются на заработавшийся PHP-процесс через 300 секунд и валят его как мамонта. Честь им и хвала. Вот только непонятно какого черта они об этом начинают в браузер кричать. Ведь браузер живет себе спокойно, никого не трогает, только периодически телеграммки посылает серверу: мол как там все идет, по плану? И в один прекрасный момент вся эта расчудесная братия врывается и кричит: Аллелуя! 504. Так вот гнать их в шею надо, потому как ни к месту их победоносные кличи в браузере. Гляньте из любопытства в консоли, сколько запросов JS отправляет и какие ответы получает за эти 300 секунд. И на какой из них они вдруг на всю страницу 504 отдают?

Когда я с beget бодался на эту тему год-полтора назад, там истина оказалась в том, что их количество запросов от JS не устраивало. Говорят мол сократите. Ну выписал я им путевку в пешее дальнее путешествие, и забыл как страшный сон. Пользователей только жалко которые у них сидят, и не могут свой сервер раз в 10 секунд опрашивать.

Они откопали вот такую ошибку в консоли:

ERROR [unique_id WXEM91vOyfEADVWFCDEAAAF-] [host kosmetichka.com.ua] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: timeout 300 is exceeded, referer https://kosmetichka.com.ua/webasyst/shop/?action=s.

На основе этого утверждают, что процесс убивается, т.к. не уложился в назначенные 300 сек.

Лопатой их по хребтине! А после вопрос задать: а с чего вдруг запрос которому от рождения секунд 5 от силы вдруг по их понятиям за 300 перевалил? В консоли ж видно время выполнения запроса? Вот пусть посмотрят. Я не большой знаток nginx (мягко говоря), могу и ошибаться, но допускаю, что они все эти запросы от JS идентифицируют как один, и в итоге так и отругиваются. Но я знаю точно, что так быть не должно. И что на нормально отконфигурированных серверах такой ерунды не происходит. Ну даже если им захотелось 504 отдать — почему на всю страницу? Ну получил бы JS кривой ответ, в консоли отругался, да дальше пошел бы. Кстати, а кто хостер-то?

Ничего не скажу, не сталкивался. Но бился бы с ними до победного. Вот окно браузера. Страница загрузилась, ответ 200. Все в норме. Вот жму кнопку, начинает работать JS. Вот раз запрос от JS — вот время его выполнения, вот ответ 200. Вот два запрос от JS, вот время выполнения, вот ответ 200. Вот три запрос от JS, вот время выполнения вот ответ 200. . Вот N запрос от JS, вот время выполнения, вот ответ 504. Откуда 504? Кому 504? От кого 504? Где эти злосчастные 300 сек? На сервере? Так мы же в браузере, и нам дела нет до того что кто там на сервере кого убивает и за что. А все запросы из браузера выполняются быстро и с ответом 200. Ну как-то так. 🙂

Я не то, чтоб не большой спец в этом деле, я — совсем никакой. Но, насколько я понял, они (их конфигурация) берут во внимание не каждый отдельный запуск скрипта, а процесс глобально. Т.е., если через вебинтерфейс выполняется некий процесс более 300 сек., они его рубят. Дебильный подход. Я почитал интернет, эта проблема существует у многих, но в случаях когда действительно процесс выполнения чего-либо затянулся (в таком случае обрубается связка nginx-apache с 504 ошибкой). Здесь, условно, браузер с определенной периодичностью запускает через js некие процессы. Так вот они работу браузера и воспринимают как затянувшийся процесс.

Вот даже любопытно. А если запустить перегенерацию эскизов, подождать секунд 10, нажать ESC (окно закроется), перейти куда-нить в том же окне настроек (например в Типы и характеристики), то даже находясь на странице с характеристиками 504 в итоге вывалится. По их «логике» — да.

Плебей, бегите оттуда, кто знает какие еще там сюрпризы 🙂 Ну или смиритесь 🙂

Не знаю, можно поэкспериментировать.

Пока же получил такой ответ:

Здесь важно понимать что все процессы JS компилируются и выполняются непосредственно в браузере. При этом JS обращается к PHP который уже запускается на сервере и имеет ограничение в 300с. Если я верно Вас понял то Вы пытаетесь перезапустить PID процесс на стороне сервера, а это, невозможно. Процесс в браузере мы затрагивать физически не может, если речь о JS, они обрабатываются непосредственно в самом браузере, сервер отдает содержимое JS в виде статического контента front-end серверов ngnix. Исходя из лога ошибок, на Вашем сайте присутствуют ошибки вида : [unique_id WXEM91vOyfEADVWFCDEAAAF-] [host kosmetichka.com.ua] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: timeout 300 is exceeded, referer https://kosmetichka.com.ua/webasyst/shop/?action=s. которые отдаются напрямую back-end сервером apache (который не обрабатывает js), и причин этому может быть множество в следствии которых Вы получите данную ошибку. К сожалению точные причины я назвать не могу так как не знаю как работает Ваш скрипт и что он запускает.

Также уточните какие скрипты запускаются на Вашем сайте для выполнения данной задачи.

Т.е. они утверждают, что это все же ошибка скриптов. Если я правильно понимаю, то это сообщение их сервера о том, что он убивает процесс, который по его мнению затянулся на 300 сек. Мне становится интересно дожать их. Доводы, что такое я встретил только у них не проходят, а необходимых знаний, к сожалению, у меня нет. ))

Мне становится интересно дожать их.

Ну это другой коленкор! ))) Про тестовую установку уже написал.

в следствии которых Вы получите данную ошибку.

Вот тут можно им, следуя современным трендам, видео заснять )) Открыть консоль браузера на вкладке Network, а далее открыть страницу генерации, запустить процесс и показывать все исходящие запросы, и то, что на каждый из них сервер отдает 200 (процесс успешно завершен). Что нету ни одного долгоиграющего запроса со стороны браузера. Ну и до тех пор, пока 504 не вывалится. Ну и спросить: почему получая на все запросы от браузера ответ 200, в один прекрасный момент непонятно от кого и на какой запрос вы получаете 504.

Но если у них самих желания понять нет, то так и буду фигню всякую писать.

Да, эксперимент удался. Сделал все в точности, и получил через 5 минут 504 ошибку совершенно на другой странице.

Ну шикарно. Я не знаю что и как они сделали, но у них стоит абсолютно жесткий лимит на «время работы» с, видимо, одного ip(или что-то похожее, техническая реализация не важна).
Судя по тому, что они даже не хотят понять суть требований и нелепости их решения, что-то менять они не собираются.
Хостинг работает, денежка падает. Если у кого-то работает что-то, выпадающее из усреднённого стада сайтов на жумлах и wp, значит это не наш клиент -)

Насколько понимаю, там ситуация такая: они «помнят» всю цепочку процессов PHP запущенных по конкретному запросу и идентифицируют ее по сессии (или чему иному) в браузере. И не смотря на то, что браузер уже получил ответ 200, когда один из дочерних процессов дстигает лимита в 300 сек, они насильно в браузер отправляют 504, вместо того чтоб по тихому убить процесс никого не оповещая. Браузеру-то сервер ответ уже дал. А тут ему второй ответ насильно прилетает. И фиг от этого ответа спрячешься, если только на другую страницу свалить. На совсем другую. Ну, например, в приложение Сайт, или Инсталлер. И то не уверен. Ребята ж упёртые 🙂

Таки браузер получает ответ не 200, а 504 через 5 минут. Посмотрел в консоли. Всегда второй запрос не получает ответа от сервера, но продолжает запускать остальные запросы. Через 5 минут на второй запрос приходит ответ 504 и кирдык.

К сожалению точные причины я назвать не могу так как не знаю как работает Ваш скрипт и что он запускает.

Ну если не лень, то сделайте им тестовую установку, пусть посмотрят сами. Хотя, результат и так понятен: вряд ли он пошевелятся. Хотя, вдруг.

Не лень, истина дороже. ))

Сделал тестовую установку. Они поигрались с ней и прислали ответ, в котором расписали почему виноваты скрипты, а не они:

Проверили ситуацию и подтвердилось все то что о чем выше говорилось. Запросы делаются js скриптом и по идеи каждый запрос должен выполняться быстро но один из процессов зависает и не возвращает ответ http://storage8.static.itmages.com/i/17/0721/h_1500632418_7626280_ee93443a2a.png JS продолжает дальше работать не обращая внимание на то что один из запросов по прежнему еще висит. Спустя 5 минут сервер убивает зависший процесс, о чем свидетельствует запись в логе [unique_id WXHU3VvOyfEACjJcC0QAAAFc] [host t1.kosmetichka.com.ua] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: timeout 300 is exceeded, referer http://t1.kosmetichka.com.ua/webasyst/shop/?action=settings и сервер возвращает ответ 504. JS согласно своей логике получив ошибку 504 от сервера прерывает выполнение и перезагружает страницу. В данной ситуации стоит выполнить отладку скрипта при обработке второго запроса(2 раза запускал процесс и именно второй запрос зависал). При этом передаются такие данные на сервер http://storage8.static.itmages.com/i/17/0721/h_1500633219_3839382_da9ceffd71.png

Я тут уточню, что процесс этот не зависший, а самый что ни на есть работающий. Это тот самый единственный runner который делает основную работу — перегенерацию. Остальные запросы — мессенджеры. Контролируют ход процесса.
Если умирает runner по отстреду или таймауту какому-то, то следующий мессенжер станет runner-ом и процесс продолжается.

Т.е. он должен дождаться окончиния всего процесса и только тогда отдаст код 200? А если сервер его хлопнул, то процесс должен продолжаться запуском следующего раннера? Я правильно понял? Если да, то в таком случае действительно вопрос почему яваскрипт реагирует на всякие ответы типа 502, 503, 504, если он и дальше способен запускать следующие процессы. Выходит все же баг?

А вот это пока и не понятно. Тут надо бы подключать непосредственно поддержку webasyst.
Делать в js-ке дебаг и смотреть что прилетает в ответах и почему оно умирает на этом хостинге.
Я пока больше нигде такого не видел, хотя на всех проектах используется nginx+php_fpm(или apache+mod_php).

Сейчас, коллеги, подождите немного. Я тут отложил все культурно-развлекательные мероприятия и решил поизучать вопрос ))) А т.к. процессы все долгоиграющие, то времени уходит порядочно. Но всякие занятные штуки уже вижу. И да, без WA, похоже, не обойтись будет. 🙂

Это точно. Выходит, что

Так вот. Описанный в первом посте «в самом начале скрипт», который работает 10 минут — это первый Runner, которому настройки PHP+nginx разрешили действовать 10 минут и более. Проблем он не создаёт: даже если он сдохнет и не отправит ничего в браузер (как собственно и должен), очень быстро запустится новый Runner и продолжит работу. (с) Леонид Вакуленко

— не есть верно. Ибо раннер сдох, отправив при этом предсмертную записку «504», а яваскрипт не смог пережить эту утрату и также свел счеты с жизнью )))

Вроде бы не совсем так. В общем рассказываю чего насмотрел. Ну во-первых для меня было удивительно что второй запрос висит до победного конца. В моем понимании этого не должно было быть. Стал смотреть. Мы же сейчас ведем речь не конкретно о перегенерации эскизов, а в целом о долгоиграющих процессах с использованием waLongActionController. Ну начал с эскизов. И действительно, второй процесс висит до посинения. Посинение у меня наступило вот с таким сообщением в логах

При этом процесс продолжился без каких либо вопросов (это, на мой взгляд, ожидаемое нормальное поведение этой конструкции)

Посмотрел экспорт большого количества товаров. За рамки execution_time выйти не удалось, но и так было видно что процесс висел пока все не экспортировалось. Стал смотреть импорт, т.к. он подольше. Все аналогично — второй процесс висит пока не отдаст концы, но сам процесс импорта работает дальше нормально

Собственно, последний вопрос, который меня интересовал во всем этом деле — откуда же я был уверен что все JS запросы получают ответ 200 в приемлемые сроки. Ответ был неожиданным )) В моих плагинах, которые используют аналогичную конструкцию, никакие процессы не зависают и все отрабатывают оперативно.

Почему так — я не знаю. Может где-то ошибся ))) Возможно, дело в объеме одной «порции» данных которую обрабатывает один проход через step. Тут только коллеги из WA подсказать могут. Ну и насколько верно что второй процесс в их скриптах висит до посинения — тоже хотелось бы от них узнать.

Но при этом я полностью согласен с Николаем:

Тут вопрос на миллион — с какого перепугу по 504-ой браузер страницу закрывает.

Этого, на мой взгляд, быть не должно. Ну получил JS в ответ не 200 а ошибку, ну съел ее, вздремнул 3 секунды, и дальше пошуровал. Не должна 504 на всю страницу лезть. Это, скорее всего, вопрос к настройке nginx. Кстати, облако WA тоже ведь на этой связке работает, если не ошибаюсь. Так может коллеги из WA внесут ясность, чтоб нам тут догадками не фонтанировать и дожать-таки строптивого хостера. 🙂

Мне вот интересен такой момент. Яваскрипт получает ответ 200 и запускает следующий процесс. А если он не получает никакого ответа или что-то из 502, 503, 504, то что он должен делать?

В том то и дело что ничего особенного. Он так и будет запускать POST-запросы пока не получит в ответе что процесс на стороне php завершен.
Тут вопрос на миллион — с какого перепугу по 504-ой браузер страницу закрывает.
В функции step видно, что если ничего не получено — опять step. Если есть ошибка — снова step.

var step = function (delay) <

delay = delay || 2000;

var timer_id = setTimeout(function () <

Смущает меня тут .error
В частности вот это «error relies on HTTP status codes and will generally not be triggered if the URL uses the file: protocol.»

В данном случае, после обрыва первого runner-а(тот самый типа «зависший» запрос) не запускается step, а показывается ошибка.

Вроде ничего не попутал. Гляньте сами, народ.

через вебинтерфейс не получается

Что происходит, когда пробуете делать это через веб-интерфейс?

60 тыс фотографий — слишком долго ждать через интерефейс. Хотелось бы как обновление поискового индекса через cli.php сделать.

Фотографии добавляются не через веб-интерфейс, а через специальный скрипт и попадаются ситуации, когда в выгрузку маркета попадают товары которые не имеют еще эскизов. Решили создать их разом и уперлись в отсутствие команды консольной.

Если фотографий много, то CLI-скрипт может не успеть выполнить всё до истечения лимита времени на исполнение PHP-скриптов, установленного в конфигурации веб-сервера.

Можно, конечно, попробовать «выкрутить» значение лимита на гигантское количество времени, но это не будет гарантировать, что однажды всё равно не получится обновить именно все эскизы.

Скрипт, который работает в веб-интерфейсе, гарантирует, что будут обновлены все эскизы, потому что он автоматически перезапускает сам себя, когда истекает серверный лимит — до тех пор, пока назначенная задача не будет полностью выполнена. PHP не позволяет реализовать то же самое без использования браузера. По крайней мере, на большинстве серверных конфигураций популярных хостингов, на которые и рассчитан Shop-Script. Поэтому ваш единственный выход скорее всего — обновлять эскизы через веб-интерфейс.

Для автоматизации процесса можете попробовать написать плагин для Shop-Script, который будет «нажимать» кнопку обновления эскизов за вас. Для этого ему, возможно, потребуется и авторизоваться за вас в бекенде магазина, если вы хотите, чтобы он работал полностью автономно.

А методика обновления поискового индекса который работает с товарами не подойдет для подобной реализации? Странно если честно — обновить поиск на 400 тыс позиций с кучей характеристик проблем нет, а применить тот же вариант для фотографии есть?

Я так понимаю надо писать плагин?

Плагин не обязательно.Создать cli-экшн. Такой же как и wa-apps/shop/lib/cli/shopSearchIndex.cli.php
Ну а в него перенести и адаптировать код пересоздания эскизов.

Увы далек от программирования, все ближе инженерка. Буду пробывать.

Прошу прощения, что вклиниваюсь. Вот у меня, например, тоже не получается пересоздать все изображения. Через 5 минут работы выбивает 502, 503 ошибка — таймаут nginx. Хостеры говорят, что у них лимит такой. Мне пяти минут не хватает.

И походу вопрос — зачем мне изображения 750х и 970х, если они у меня нигде не используются? А исключить их, насколько я понял, нельзя.

а при увеличении картинки в шаблоне не они часом используются.

Можно их в разделе изображения удалить. Но на 99% они используются у вас в шаблоне.

У меня в шаблоне используются другие размеры. Приведенные размеры используются в стандартных шаблонах. Мне они не нужны.

Они в бэкенде используются. 96×96, 200, 970 — 100%. Насчёт 750 не уверен.

Да, согласен, 970 используется. Но 750 не встречал нигде.

Через 5 минут выбивает ошибку (502, 503, 504) time-out nginx.

Плебей, всё очень просто. если не вдаваться в подробности, то нажимаешь перегенерецию. и ждёшь. выскочила ошибка, веришь и ждёшь. потому что самое интересно, что если оставишь страницу в покое, она будет продолжать работать и регенерация будет идти. поэтому в зависимости от количества товаров. на каждые 10 000 товаров, заложи ожидать и не трогать страницу 1 час.

Через час можешь обновлять страницу и радоваться полученному результату.

А вот что происходит под капотом — http://recordit.co/ATjjpo9971

Пробовал. У многих товаров картинки не перегенерируются. После 504-й ошибки запросы продолжают идти, но пару десятков, и останавливаются.

А никто в это время кеш не чистит? Потому что установка плагинов, либо ручная чистка кеша приводит к остановке всей этой истории. как я помню.

Источник

[beta]

Apache mod_lsapi is a module based on LiteSpeed Technologies API for PHP, Ruby and Python. It offers excellent PHP performance, low memory footprint coupled with great security and support for opcode caching.

How it works

What is lsphp

lsphp — PHP + LSAPI. What is LSAPI? LiteSpeed Server Application Programming Interface (LSAPI) is designed specifically for seamless, optimized communication between LiteSpeed Web Server and third party web applications. Now this protocol is available for Apache 2.2/2.4.

Using LSAPI, we have seen higher performance than Apache with mod_php, easier installation than php-fpm and easier integration with any control panel. LSAPI means faster and more stable dynamic web pages.

Requirements

CageFS (installed and initialized)

Alt-PHP

Apache with SuExecuUserGroup directive for each user’s VirtualHost,

mod_ruid2 disabled

apache itk disabled

Configuration Options

Example configuration

LoadModule lsapi_module modules/mod_lsapi.so
 
<IfModule lsapi_module>
  AddType application/x-httpd-lsphp .php
  lsapi_backend_connect_timeout 100000
  lsapi_backend_connect_tries 10
  lsapi_backend_children 20
  lsapi_backend_pgrp_max_idle 30
  lsapi_backend_max_process_time 300
  lsapi_debug Off
</IfModule>

Secret File

When installed, liblsapi will automatically create secret file used by mod_lsapi to communicate with backend:

/etc/sysconfig/modlsapi.secret

owner root:root

perms: 400

for making security pass PHPRC and UID|GID on start lsphp

Algorithm of creating:

/bin/dd if=/dev/random of=/etc/sysconfig/modlsapi.secret bs=16 count=1

Command Line Tools (cPanel only)

Use the following syntax to manage MODLSAPI istall utility:

/usr/bin/switch_mod_lsapi [OPTIONS]

Options:

—setup — setup mod_lsapi configurations for apache

—uninstall — uninstall mod_lsapi from apache

—enable-domain — enable mod_lsapi for individual domain

—disable-domain — disable mod_lsapi for individual domain

—enable-global — sets up mod_lsapi as a default way to serve PHP, making it enabled for all domains. Once that mode is enabled, you cannot disable mod_lsapi for individual domain

—disable-global — disable mod_lsapi  as a default way to serve PHP, disabling mod_lsapi for all domains, including those selected previously using —enable-domain

—build-native-lsphp — build native lsphp for cPanel

This tool:

What commands are available for different control panels:

Different PHP versions (without PHP Selector)

mod_lsapi allows to use different handlers for different php versions. For example, a file with extension .php53 can be handled by php5.3 and a file with extension .php55 handled by php5.5 without PHP Selector.

Here is an extra config file which allows to set handlers and php binaries for these handlers — /etc/container/php.handler. Example of this file:

# cat /etc/container/php.handler

application/x-lsphp53 /opt/alt/php53/usr/bin/lsphp

application/x-lsphp55 /opt/alt/php55/usr/bin/lsphp

Default handler for lsphp is — application/x-httpd-lsphp, if I set in .htaccess such options:

AddType application/x-httpd-lsphp .php5 .php4 .php .php3 .php2 .phtml

AddType application/x-lsphp53 .php53

File index.php53 will be processed by php 5.3, but index.php processed by php standard, placed at /usr/local/bin/lsphp.

mod_lsapi as suPHP replacement (cPanel)

mod_lsapi is a drop in replacement for suPHP. No configuration changes need to be done. To switch from suPHP to mod_lsapi:

Switch the whole server (disables suPHP, all domains will be serviced by mod_lsapi):

/usr/bin/switch_mod_lsapi —enable-global

Switch individual domains:

/usr/bin/switch_mod_lsapi —enable-domain test.example.tst — enablesmod_lsapi [only for domain test.example.tst]

Manually add mod_lsapi for a particular domain: — add to .htaccess file for the domain:

AddType application/x-httpd-lsphp .php5 .php4 .php .php3 .php2 .phtml

Note: This will work only after /usr/bin/switch_mod_lsapi —setup had been called.

Steps to reproduce the issue

1. Switching from PHP 5.6.17 to PHP 7 on the server
2. Open ‘System’ -> ‘System Information’ in the backend.

Expected result

Show system info…

Actual result

Internal Server Error

System information (as much as possible)

Linux
Database version: 5.5.44-MariaDB-cll-lve
Webserver: Apache/2
litespeed
Joomla! 3.5.0 Stable

Additional comments

Form the error logs:

[Wed Mar 30 15:39:32.944881 2016] [lsapi:error] [pid 978448:tid 140354095249152] [client 93.186.191.244:44338] [host www.inxpact.nl] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: nothing to read from backend socket, referer: https://www.inxpact.nl/administrator/index.php?m9hqj1u6lj
[Wed Mar 30 15:39:32.944923 2016] [lsapi:warn] [pid 978448:tid 140354095249152] [client 93.186.191.244:44338] mod_lsapi: re-sending previously crashed request again (1), referer: https://www.inxpact.nl/administrator/index.php?m9hqj1u6lj
[Wed Mar 30 15:39:32.944955 2016] [lsapi:error] [pid 978448:tid 140354095249152] [client 93.186.191.244:44338] [host www.inxpact.nl] Backend error on sending request(GET /administrator/index.php?option=com_admin&view=sysinfo HTTP/1.1); uri(/administrator/index.php?option=com_admin&view=sysinfo) content-length(0) (lsphp is killed?): SendRequest: write to backend socket failed: errno 9, referer: https://www.inxpact.nl/administrator/index.php?m9hqj1u6lj
[Wed Mar 30 15:40:41.482596 2016] [lsapi:error] [pid 978558:tid 140354212747008] [client 93.186.191.244:44362] [host www.inxpact.nl] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: nothing to read from backend socket, referer: https://www.inxpact.nl/administrator/index.php?option=com_cache
[Wed Mar 30 15:40:41.482639 2016] [lsapi:warn] [pid 978558:tid 140354212747008] [client 93.186.191.244:44362] mod_lsapi: re-sending previously crashed request again (1), referer: https://www.inxpact.nl/administrator/index.php?option=com_cache
[Wed Mar 30 15:40:41.482667 2016] [lsapi:error] [pid 978558:tid 140354212747008] [client 93.186.191.244:44362] [host www.inxpact.nl] Backend error on sending request(GET /administrator/index.php?option=com_admin&view=sysinfo HTTP/1.1); uri(/administrator/index.php?option=com_admin&view=sysinfo) content-length(0) (lsphp is killed?): SendRequest: write to backend socket failed: errno 9, referer: https://www.inxpact.nl/administrator/index.php?option=com_cache
[Wed Mar 30 15:42:21.255995 2016] [lsapi:error] [pid 978448:tid 140354204354304] [client 93.186.191.244:44390] [host www.inxpact.nl] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: nothing to read from backend socket, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins&view=plugins
[Wed Mar 30 15:42:21.256036 2016] [lsapi:warn] [pid 978448:tid 140354204354304] [client 93.186.191.244:44390] mod_lsapi: re-sending previously crashed request again (1), referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins&view=plugins
[Wed Mar 30 15:42:21.256070 2016] [lsapi:error] [pid 978448:tid 140354204354304] [client 93.186.191.244:44390] [host www.inxpact.nl] Backend error on sending request(GET /administrator/index.php?option=com_admin&view=sysinfo HTTP/1.1); uri(/administrator/index.php?option=com_admin&view=sysinfo) content-length(0) (lsphp is killed?): SendRequest: write to backend socket failed: errno 9, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins&view=plugins
[Wed Mar 30 15:44:05.897178 2016] [lsapi:error] [pid 978448:tid 140354305066752] [client 93.186.191.244:44452] [host www.inxpact.nl] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: nothing to read from backend socket, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins
[Wed Mar 30 15:44:05.897211 2016] [lsapi:warn] [pid 978448:tid 140354305066752] [client 93.186.191.244:44452] mod_lsapi: re-sending previously crashed request again (1), referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins
[Wed Mar 30 15:44:05.897240 2016] [lsapi:error] [pid 978448:tid 140354305066752] [client 93.186.191.244:44452] [host www.inxpact.nl] Backend error on sending request(GET /administrator/index.php?option=com_admin&view=sysinfo HTTP/1.1); uri(/administrator/index.php?option=com_admin&view=sysinfo) content-length(0) (lsphp is killed?): SendRequest: write to backend socket failed: errno 9, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins
[Wed Mar 30 15:44:16.634708 2016] [lsapi:error] [pid 978448:tid 140354095249152] [client 93.186.191.244:44468] [host www.inxpact.nl] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: nothing to read from backend socket, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins
[Wed Mar 30 15:44:16.634756 2016] [lsapi:warn] [pid 978448:tid 140354095249152] [client 93.186.191.244:44468] mod_lsapi: re-sending previously crashed request again (1), referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins
[Wed Mar 30 15:44:16.634781 2016] [lsapi:error] [pid 978448:tid 140354095249152] [client 93.186.191.244:44468] [host www.inxpact.nl] Backend error on sending request(GET /administrator/index.php?option=com_admin&view=sysinfo HTTP/1.1); uri(/administrator/index.php?option=com_admin&view=sysinfo) content-length(0) (lsphp is killed?): SendRequest: write to backend socket failed: errno 9, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins
[Wed Mar 30 15:44:55.081145 2016] [lsapi:error] [pid 978558:tid 140354347030272] [client 93.186.191.244:44528] [host www.inxpact.nl] Error receiving response header (lsphp is killed?): ReceiveResponseHeader: receive pkg hdr failed: ReceivePkgHdr: nothing to read from backend socket, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins
[Wed Mar 30 15:44:55.081189 2016] [lsapi:warn] [pid 978558:tid 140354347030272] [client 93.186.191.244:44528] mod_lsapi: re-sending previously crashed request again (1), referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins[Wed Mar 30 15:44:55.081214 2016] [lsapi:error] [pid 978558:tid 140354347030272] [client 93.186.191.244:44528] [host www.inxpact.nl] Backend error on sending request(GET /administrator/index.php?option=com_admin&view=sysinfo HTTP/1.1); uri(/administrator/index.php?option=com_admin&view=sysinfo) content-length(0) (lsphp is killed?): SendRequest: write to backend socket failed: errno 9, referer: https://www.inxpact.nl/administrator/index.php?option=com_plugins

Добавить ответ