Форум Apache

Серверу нужно иногда подливать большой массив данных. Для удобства сделал скрипт на ПХП. Но доступных на хостинге 150 секунд на выполнение не хватало. Предложили перейти на VPS, где можно будет устанавливать свои лимиты. Перешли. В каждом цыкле обрабатывается по 100 записей и, на всякий случай запускается
set_time_limit(30);
продление на 30 секунд, чтоб наверняка хватило времени выполнения.
Но, похоже, set_time_limit все так же не работает. Изменил глобальные настройки
max_execution_time 1000
все равно получаю
"504 Gateway Time-out
nginx/1.2.1"
(как и раньше).
Как решить проблему?
Версии и модули:
PHP как модуль Apache
PHP как CGI
apache2-2.2.22-13+deb7u2
Модуль FastCGI для веб-сервера Apache ВЫКЛЮЧЕН
nginx-1.2.1-2.2+wheezy2
php5-5.4.4-14+deb7u14

Остальное, по идее, не должно влиять

Вписал
set_time_limit(0);
не помогает. phpinfo выдает
max_execution_time 1000
но скрипт работает пинуты 2 и сдыхает:

504 Gateway Time-out
nginx/1.2.1

А может и не стоит издеваться на сервером?

Время и ресурсы как не крути не могут быть бесконечны, и не стоит подгонять ограниченные ресурсы под каждое новое не получающееся. Может быть поставить вопрос:

1) Откуда массив - это внешние данные или это результат работы своего скрипта? Возможна ли оптимизация во втором случае?
2) Оптимизирована ли обработка этого массива? Возможно решение выбрано не эффективное?
3) Если первые два вопроса ответа не дают, то возможно ли разбить задачу на этапы?

Если б я мог. Там таблица в базе за 500 тысячь записей. И к ней нужно подливать данные таких же размеров, заменяя существующие записи при совпадении уникалных ключей (но делая некоторые предварительные вычисления, что еще больше увеличивает нагрузку).
Но делать это нужно раз в месяц. Поэтому это не убивает сервер напрочь.
Можно, конечно, нарезать данные на 500 фрагментов и целую неделю заниматься их подливанием... Но вы понимаете, что с такими нагрузками на человека компьютер становится бесполезным. Работать должна машина. На локальном компьютере для выполнения операции хватает 700 секунд. На ВПС скрипт не выполняется долше 60. Хоть каждый раз делай все на локалке, а потом перезаливай базу по фтп...
Но есть же какие-то возможности управлять временем выполнения скрипта?

Ну если вы третируете max_execution_time, значит видимо уже прочли и о том, что ошибка 504 возникает еще и в связках где установлен nginx в качестве фронтенда и Apache в качестве бэкенда. А возникает она потому, что при возросшей нагрузке, при которой Apache не успевает отдавать HTTP-ответы, новые запросы встают в очередь. Торчат они там, но так и не получают обслуживания, поэтому соединения сбрасываются.
Следовательно читали и о рекомендациях в таких случаях - добавить ресурсов: оперативной памяти, увеличить количество процессов httpd (Apache).
Ну а о том, что надо оптимизировать скрипты, и это в первую очередь, или изменить подход к решению задачи, уже говорилось.

процесс только один.Это же не яндекс с миллионами посетителей. Это база для внутренних нужд компании. Ее периодически нужно обновлять. Но это только 1 процесс раз в месяц. Так что, именно он и торчит. Памяти хватает с лихвой (512 метров), так как sql читается построчно, а фрагменты новых данных разбиты на несколько частей по 2-3 мегабайта (из различных источников собираются в кучу). Поэтому вопрос в том, помечу процесс сбрасывается и как это исправить.
Я догадываюсь, что не обошлось без nginx. Но как исправить проблему?
Я, кстати, написал такой скрипт:

<?// проверка допустимости времени выполнения set_time_limit(60); //ini_set('max_execution_time', '70'); $time0=$time1=time(); while (true):     $time2=time();     if($time2-$time1 > 0){         $time1=$time2;         $time=$time2-$time0;         echo '<p>'.$time.'</p>';     }     if($time >1000){         break;     } endwhile; ?>

Пытаясь определить, сколько же времени скрипту удастся выполняться. Оказалось, что 30 секунд выполняется, 40 выволняется. А вот на
set_time_limit(60);
происходит "504 Gateway Time-out".

Скрипту, как понимаете, ни памяти много не требуется, ни во множестве процессов он не учавствует. ЦПУ он, конечно, подгружает. Но требовалось имитировать выполнение какой-то работы...

К аналогичному результату приводит такой скрипт

<?// проверка допустимости времени выполнения set_time_limit(60); //ini_set('max_execution_time', '70'); $time0=$time1=time(); while (true):     sleep(5);     $time2=time();     $time=$time2-$time0;     echo '<p>'.$time.'</p>';     if($time >1000){         break;     } endwhile; ?>

А он, как вы понимаете, нагрузки не создает. Только время танет.

Ну если ваш код, это схожее с этим по сути, то даже и без нагрузки на ресурсы уже плохо.

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

Прочтите http://ru2.php.net/manual/ru/control-structures.declare.php. С помощью этого можно выявить слабые места в коде, то есть те участки, которые сжирают время, а ведь время пусть ничего "не воруя", но потраченное впустую, это тоже нагрузка.

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

Вобщем, залез в nginx.conf, вписал

proxy_read_timeout 1000;
proxy_connect_timeout 1000;

перезапустил сервер...

Обработка "BASE1_1.csv" выполнена за 562 секунд

Есть еще 4 куска базы, но, думаю, там проблем уже не будет.

А вы, между прочем, если знали. где рыть, могли бы и подсказать. Я программист, а не администратор веб-серверов. Тратить часы на выяснение капризов сервера мне не очень целесообразно, так как потом еще лет 5 не придется с этим гемороем сталкиваться (а к тому времени все изменится). Специалисту по серверам изменить настройку дело одной минуты, а у меня на то, чтобы разобраться, ушло столько же времени, сколько на написание программы, которая на этом сервере отказалась выполняться.

>к ней нужно подливать данные таких же размеров, заменяя существующие записи при совпадении уникалных ключей

это sql может без всякого php

>(но делая некоторые предварительные вычисления, что еще больше увеличивает нагрузку).

какого рода вычисления?

Что-то достаточно простое (между старой строкой в таблице и добавляемой) тоже вполне можно из php убрать в SQL.

не понятна фраза "можно из php убрать в SQL".
Вообще, вычисления такого рода:

$sql='SELECT id FROM '.table_articles.' WHERE brand='.quote_smart($data[0]).' AND (                 FIND_IN_SET(article1,"'.$data[1].','.$data[2].','.$data[3].'")                 OR                 FIND_IN_SET(article2,"'.$data[1].','.$data[2].','.$data[3].'")                 OR                 FIND_IN_SET(article3,"'.$data[1].','.$data[2].','.$data[3].'")                 )';                 $result=mysql_query($sql) or die('<p>'.__LINE__.' '.mysql_error().' '.mysql_errno());                 $sql_ar=mysql_fetch_assoc($result);                                  if($sql_ar['id']){                 ...

Если бы это было в моей власти, я бы за такую организацию данных уволнял с должности. Но, к сожалению, мне приходится работать именно с такой структурой. И я сдалал код настолько оптимальным, насколько это возможно

>не понятна фраза "можно из php убрать в SQL".

Если строки, в которых требуется модификация, можно идентифицировать неким ключом (полем или набором полей), то оператор INSERT ... ON DUPLICATE KEY UPDATE ... в целом позволяет за один запрос прогнать список строк, добавляя в таблицу несуществующие (по ключу) строки, и наоборот, определенным образом модифицируя строки, для которых ключевое соответствие найдено.
Пример можно найти, например, в этой теме.

>Вообще, вычисления такого рода:
>
я это понял как если добавляемый brand совпадает совпадает с имеющтмся brand и какой-нибудь из трех новых article совпадает с каким-нибудь из трех имеющихся article.

>
>Если бы это было в моей власти, я бы за такую организацию данных уволнял с должности. Но, к сожалению, мне приходится работать именно с такой структурой. И я сдалал код настолько оптимальным, насколько это возможно

сочувствую.
а если расписать все это цепочкой

WHERE b = $b  AND  (   a1=$a1 OR a1=$a2 OR a1=$a3  OR a2=$a3 OR a2=$a2 OR a2=$a3  OR a3=$a3 OR a3=$a2 OR a3=$a3 )

быстрее не выйдет?
в любом случае - сочувствую.

подозреваю, что много OR не ускорят работу. Даже если финдинсет работает медленней (подозреваю, что быстрей), ориентироваться (а в случае, если начальству опять что-то станет "виднее", то и корректировать), без многих OR проще.

если есть возможность, попробуйте для apache увеличить параметр ThreadStackSize, мне помогало

*оффтоп*
зашел на ваш сайт, указанный в профиле. посчитайте сколько раз на нём встречается слово студия. это просто какое-то сумасшествие. студия, студия, студия, студия, веб-студия, дизайн-студия, студия, студия ....

Сегодня алгаритм стал веселее:

if($data[0]){                     $sql='SELECT id FROM '.table_articles.' WHERE brand='.quote_smart($data[0]).' AND (                     article1<>"" AND FIND_IN_SET(article1,"'.$data[1].','.$data[2].','.$data[3].'")                     OR                     article2<>"" AND FIND_IN_SET(article2,"'.$data[1].','.$data[2].','.$data[3].'")                     OR                     article3<>"" AND FIND_IN_SET(article3,"'.$data[1].','.$data[2].','.$data[3].'")                     )';                 }else{                     $sql='SELECT id FROM '.table_articles.' WHERE                      article1<>"" AND FIND_IN_SET(article1,"'.$data[1].','.$data[2].','.$data[3].'")                     OR                     article2<>"" AND FIND_IN_SET(article2,"'.$data[1].','.$data[2].','.$data[3].'")                     OR                     article3<>"" AND FIND_IN_SET(article3,"'.$data[1].','.$data[2].','.$data[3].'")                     ';                 }

Но завтра он усложнится в несколько раз.
Господи! Разве можно держать данные в таком виде?!

Если б кто знал, как я полюбил REPLACE после знакомства с этой структурой данных...

Это не обработка, а только лишь отбор первичного ключа.
А дальше-то там что происходит?
И, кстати, что всё-же означают все эти article1...article3?

Это у одной продукции 3 артикля. При чем в исходных данных они могут быть вписаны в любой последовательности. Кроме того, может не указываться производитель. Кроме того, артикли могут быть разными, но если один совпал, значит продукция та же...
Но для гарантии, что продукция та же, потребуется сравнивать и описание.
Вобщем, отличный пример того, как нельзя организовывать данные.
А дальше все просто: если такой записи еще нет, добавить, если есть, заменить ряд полей, потому что они могут изменить значение.

> Это у одной продукции 3 артикля.
артикль - грамматический элемент языка. Причем здесь продукция? Может артикул?

> При чем в исходных данных они могут быть вписаны в любой последовательности.
> Но для гарантии, что продукция та же, потребуется сравнивать и описание.

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

Может и артикул. Я их путаю. Но это не принципиально.
Руководство считает, что программисты всесильны и решат любую задачу.
Вот и приходится решать. Раньше такие надежды возлагали на колдунов, шаманов, жрецов... Ныне на программистов.

так решайте!
создавайте новую схему БД
создавайте правильные таблицы
перебрасывайте в них данные
в рамках нормальной схемы обновления будут идти мгновенно.

проблема в исходных данных. Я не могу на них повлиять. Они заполняются в экселе как попало разными операторами. Моя задача хоть как-то упорядочить исходный хаос.

почему это не можете?
Можете.
Составляете регламент заполнения документа, утверждаете у начальства его содержание и сроки внедрения.