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

[Dmitry Koteroff]

si, аргументируйте.

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

 

[AnToXa]

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

 

[Dmitry Koteroff]

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

 

[AnToXa]

дело хозяйское
кстати, а для ibase нету чего-то вроде sqlrelay ?

 

[si]

Dmitry Koteroff
чего там непонятного ?

по вашему при смерти shm сегмент удаляется, тогда имеем:

процесс 1 добавляет свой PID в shm и идет в ibase_query
процесс 2 добавляет свой PID в shm и идет в ibase_query
процесс 2 умирает убивая (по вашему) память
процесс 1 висит, но про него никто не знает
процесс 3 смотрит в shm на предмет кого бы замочить, и никого не находит

-~{}~ 17.06.05 13:01:

AnToXa

кстати, а для ibase нету чего-то вроде sqlrelay

для oracle он (около года назад смотрел) тормозит до не приличия на простейших запросах, в сотни а то и тысячи раз ..

 

[Dmitry Koteroff]

> процесс 2 умирает убивая (по вашему) память
Это не "по моему", а "по вашему". Память убивается только тогда, когда умирает ПОСЛЕДНИЙ процесс, который ее использует. С семафорами, кстати, то же самое. В этом и преимущество такого рода решения по сравнению с файлами: использование зависимых ресурсов.

 

[si]

Dmitry Koteroff

Ну и какой тут мусорный файл для случая с разделяемым сегментом памяти? Процесс умер, сегмент освободился автоматом, разве нет?

слова ПОСЛЕДНИЙ я тут в упор не вижу. вы наверно удивитесь но это не всегда так, сегмент может остаться висеть и без процессов.

кстати чтобы писать в shm прийется еще и семафоры использовать ...

 

[Dmitry Koteroff]

> сегмент может остаться висеть и без процессов
Сомневаюсь, что ядро допустит такую утечку ресурсов.

> прийется еще и семафоры использовать
Не обязательно. Зависит от организации блока этой самой памяти. Например, если у каждого PID будет своя фиксированная ячейка для timestamp, конфликтов не возникнет.

 

[AnToXa]

Сомневаюсь, что ядро допустит такую утечку ресурсов.

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

 

[tony2001]

AnToXa
si

<mode type=pedantic>
ну, допустим, c PHP это невозможно, т.к. при выделении сегмента его координаты добавляются в список ресурсов, а все ресурсы (включая shm-сегменты) разрушаются (закрываются|освобождаются) при окончании работы скрипта.
так что, по сути Антоха прав, но в приложении к PHP - нет.
</mode>

 

[si]

tony2001
мы не рассматриваем нормальное завершение процесса, а именно его безвременную кончину, если процесс падает от сигнала, ничего такого происходить не будет.
да и нафига нужен такой сегмент который виден только 1 процессу и по во время его работы, это shared memory? ее идея что она висит в памяти и многие просессы могут ее юзать.
не смотрел когда они чистятся в РНР но явно не при окончании работы скрипта, возможно при shutdown веб сервера.

-~{}~ 17.06.05 15:48:

Dmitry Koteroff
если я правильно поная как вы предлагаете организовать память так:

выделяем кусок памяти размером 0xFFFF (MAX_PID) * 4
каждый процесс пишет timestamp по смещению равному его PID

процесс убийца считывает все память, ищет там просроченные PID и их начинает убивать, после чего пишет по этому смещению 0

не уверен на 100% но это может и будет работаьь без взаимной синхронизации.

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

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

 

[Dmitry Koteroff]

Если начнут палить одновременно, ничего страшного не
произойдет - просто один попадет, а в других будет ошибка вызова kill. Не страшно.

> 0xFFFF (MAX_PID) * 4
Да, именно. Но только я вот тут подумал: такой способ имеет громадный минус: он тормозить будет, потому что придется каждый раз сканировать весь сегмент в поисках ненулевого элемента. Так что, наверное, лучше все же сделать с семафорами или хотя бы с flock-ом: создавать в начале "/tmp/".getmypid(), открывать и ставить на него flock(). Это разовая операция при старте скрипта, в дальнейшем, при выполнении ibase_query(), достаточно будет вызывать LOCK_EX и LOCK_UN. Это по-преждему совместимо с Windows, если использовать shmop_*().

 

[Falc]

Dmitry Koteroff
Могу предложить заменить UPDATE на INSERT тогда проблемы с NO WAIT быть не должно. А по крону пересчитывать инесеры. Правда данное решение будет тормознее, но на производительности всего сайта сказатся должно не сильно.