Лимит на реальное (не процессорное!) время работы скрипта

[Dmitry Koteroff]

> вообще, Интербейз там откуда?
> наверняка ведь какая-то система внутренняя
> с ним работает, так?
Нет. Обычная база для обычного сайта. Ничего особенного. Используется так же, как могла бы использоваться MySQL - но только там СУЩЕСТВЕННО, что нужны триггеры, хранимые процедуры, представления и вообще все, что есть в полноценных реляционных базах.

 

[alexhemp]

Dmitry Koteroff

Я читаю обычно статьи на ibase - http://ibase.ru/devinfo/ibtrans.htm - она от 2003 года а не от 2000

Я так понимаю что у вас конфликт обновления, но по сути это тот-же дедлок.

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

Мне кажется - что это работа SQL сервера.
Из указанного Выше документа:

в Yaffil введен дополнительный параметр LOCK_TIMEOUT, который относится ко всем транзакциям режима WAIT
- если такая транзакция попадает на конфликт обновления, то через LOCK_TIMEOUT секунд она будет переведена (однократно) в режим NOWAIT и получит сообщение о конфликте. Используется в случаях, когда используются WAIT-транзакции, и "долгоживущие" транзакции, которые своими обновлениями могут надолго заблокировать wait-транзакции

Т.к. этой опции нет в IB/FB то и не рекомендуются длинные WAIT транзакции.

А в скрипте можно классически сообщать об ошибке и показать те-же данные.

Опять-же - есть ли вероятность что блокирующая операция так меняет данные, что заблокированная уже не имеет смысла?

Извините, если опять неверно понял Вас.

 

[Dmitry Koteroff]

> А есть какие-то гарантии что требуемый ресурс
> освободиться за некоторе время?
Нет, однако есть правило: если за 10 секунд не освободится, значит, надо скрипт убить. Такая ситуация трактуется, например, как наличие длительной параллельной операции с базой, выполняемой администратором - или что-то подобное. Скрипт должен гарантировано уложиться в 10 секунд, что бы ни произошло, но более короткое время он обязан все же ждать.

 

[si]

и того что мы имеем:
средствами IB нам выйти из этой ситуации, тогда варианта 2
- менять IB на что-то другое
- делать это на стороне скрипта

тут вариантов тоже немного. alarm в mod_pho не работает, значить кто-то другой должен скрипт убивать, либо апач , либо какой-то другой процесс который знает о том кого убивать.
на мой взгляд вариант который предложил Vasya самый приличный.

даже если сравнивать затраты на перенос на другую базу и этот второй явно будет дешевле.

хотя у него есть существенный минус, это отсутствие красивого сообщения об ошибке
-~{}~ 15.06.05 12:23:

/me для пробы уже давно его реализовал бы на Net:aemon

 

[AnToXa]

выход собсна очевиден - отказаться от выполнения этого дела в php
кмк минимум - в mod_php, юзать cgi что-ли, может быть чуть-чуть патченый на предмет сигналов.

 

[alexhemp]

Dmitry Koteroff
Может быть для подобных операций ввести спец. флаг в базе, типа "административные работы". И все операции по обновлению не производить в эти моменты. Тогда и блокировки не будут возникать.

Боюсь решение возможно только как "костыль" ибо в оригинальном IB и FB нет LOCK_TIMEOUT вообще.

Тогда действительно - нужно сборщик "мусора" писать... Или в цикле несколько попыток делать и потом отлуп юзеру показывать, если скажем 5 попыток через 1 секунду не прошли.

 

[si]

alexhemp
были разговоры что год Yaffil будет переносится в FB, что-то делается в этом направлениии ?

 

[Dmitry Koteroff]

> Может быть для подобных операций ввести спец. флаг в
> базе, типа "административные работы". И все операции
> по обновлению не производить в эти моменты. Тогда и
> блокировки не будут возникать.
Это неустойчивое решение, как карандаш, стоящий на острие. Кто-то может этот флаг случайно забыть взвести. Кто-то - забыть сбросить (это уже гораздо серьезнее, ибо "забыть сбросить" можно просто при падении приложения). Да мало ли еще что.

А вот интересно, если в PHP-скрипте вызвать setenv() на время работы ibase_query(), то другой, внешний демон сможет ли увидеть его переменные окружения (измененные) и соответствущим образом отреагировать? Наверняка ведь сможет. По крайней мере, argv[0] из программы точно можно менять; наверняка можно и переменную окружения.

Уж больно не хочится связываться со всякими там семафорами, разделяемой памятью, сокетами и т.д.

 

[Screjet]

setenv() не поможет.
Самое простое = высылать сигнал демону, а с разделяемой памяти забирать результат.

 

[alexhemp]

Dmitry Koteroff

По моему демон - это Dirty Hack... Где гарантии что кто-то не прибъет демона...

Блокировка по сути - тот-же флаг, который просто не снимается...

 

[Dmitry Koteroff]

Почему это putenv() не поможет?

Только что поставил переменную, сделал system('set') и увидел, что переменная поставилась. Потом посмотрел в исходники функции php_putenv() - там честно вызывается системная функция putenv(), т.е. должно срабатывать, по идее...

Переменные окружения процесса выдает команда:

ps e --width=1000 -p <PID>

Можно и в /proc/PID/environ смотреть. Правда, пока почему-то для некоторых процессов не выдаются переменные окружения, а для некоторых - выдаются. Пока не успеваю разобраться.

С разделяемой памятью связываться не хочу - слишком сложно это. Да и подержка соответствующая в PHP нужна (в отличие от putenv(), которая есть везде).

 

[Screjet]

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


А поддержка в ПХП есть. Целый раздел посвящен этому "Semaphore, Shared Memory and IPC Functions" в мане.

 

[Dmitry Koteroff]

Не понял, при чем тут дочерние и родительские процессы. Речь о том, что нужно как-то сообщить ВНЕШНЕМУ демону-палачу, что процесс находится внутри ibase_query() уже больше 10 секунд. Почему, Вы говорите, через переменные окружения это не получится сделать?..

 

[si]

Dmitry Koteroff
а зачем изобретать велосипед да еще такой кривой ? есть вполне стандартные средства IPC, причем в большем количестве.

вы предлагаете постоянно сканировать все процессы и смотреть что там у них в env ? это как-то не оптимально получается, куда эффективнее будет если демон просто ждет команду

 

[Dmitry Koteroff]

"Ждет команду" - это
а) синхронное событие (и лишняя нагрузка в момент выполнения КАЖДОГО запроса);
б) понижение масштабируемости из-за излишних зависимостей (так скрипт должен "знать" о демоне, а демон - о скрипте; в варианте с переменными окружения же - скрипт о демоне ничего знать не должен, он будет работать и без всякого демона вообще, даже в Windows).

Постоянно сканировать процессы (а в реальности пару раз в минуту будет достаточно) - довольно дешевая операция. И, главное, она полностью асинхронная, так что скрипты ее не заметят даже.

 

[si]

Dmitry Koteroff
если рассуждать логично, с точки зрения безопасности один процесс не должен видеть env другого

тогда такой вариант

<?
	$fname =  '/tmp/ibase_query_'.posix_getpid();
	touch($fname);
	
	ibase_query();
	
	unlink($fname);
?>

и на шеле

#!/bin/sh

for ((;1;)); do
        d=$(date -d "-10 sec" +"%Y%m%d%H%M.%S")

        echo "Step: $d "

        touch -t $d /tmp/ibase_query

        for f in `find /tmp -name ibase_query_* ! -newer /tmp/ibase_query`; do
                p=${f##*_}
                echo "PID: $p"
                #kill $p
                rm -f $f
        done

        sleep 1
done

 

[AnToXa]

Dmitry Koteroff

"Ждет команду" - это
а) синхронное событие (и лишняя нагрузка в момент выполнения КАЖДОГО запроса);

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

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

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

чтобы написать в сокет или в файл никаких особых модулей не надо.

 

[Vasya]

1. Можно пропатчить PHP IB либу на предмет того, чтобы она писала в сокет (создавала файл, ...) каждый раз при вызове ibase_query();

а) синхронное событие (и лишняя нагрузка в момент выполнения КАЖДОГО запроса);

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

2. Можно пропатчить IB клиент, чтобы он сам завершал с ошибкой функцию ibase_query(); по истечение определенного интервала, если она вызвана из PHP. Тогда ведь даже сообщения в PHP появятся...

tony2001: у клиента Interbase нет какого-то своего таймаута?

Немного дописать IB клиент, а?

 

[Dmitry Koteroff]

> буддет чужой программист читать ваш код и гадать
> нафига сдался этот putenv
Ну, знаете... Не ожидал такого замечание, не ожидал. Комментарии-то давно еще придумали, лет уже 50 как...

> unlink($fname);
Ага. Вот не дойдет до этого оператора дело, и останется файл мусорный висеть. Его, конечно, может демон сшибать, но вдруг демон не используется? Тогда в худшем случае получим засорение /tmp временными файлами, которые некому чистить. Вот это я и называю "плохой масштабируемостью".

Вообще, не хотелось бы с файлами связываться все-таки. Как-то криво это. База на то и придумывалась, чтобы можно было только с ней и работать, а тут файлы какие-то...

Насчет "пропатчивания" - хотелось бы обойтись без. Потому что это снижение переносимости на сей раз.

 

[AnToXa]

Ну, знаете... Не ожидал такого замечание, не ожидал. Комментарии-то давно еще придумали, лет уже 50 как...

comments always tend to be out of sync with the code (c) кто-то шибко умный

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

Ага. Вот не дойдет до этого оператора дело, и останется файл мусорный висеть

заверните в деструктор, один фик выполнится по окончании работы скрипта, а еще лучше: удаляйте перед созданием и вся любовь, предваряя возражения: разные процессы юзают разные файлы, скажем ibase_killme.<pid процесса>.

и вообще напишите application server и не грейте мозги