Ответ

Misha v.3 18.09.2013 13:38 / 18.09.2013 13:40

1. то, что код один и тот-же, ещё не означает, что он правильный. очень может быть, что при разных входных даных (form, DB, cookie, hashfile) он работает сильно по разному.

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

3. вы называете вылетами завершение по вашему throw или по записям в серверном логе с out of memory? просто по моему это могут быть сильно разные вещи. ваш watchdog некорректен, т.к. смотрит на текущее время.
например у вас есть запрос ^int:sql{select 2+2}
время его выполнения никогда не учитывается в stime. но если sql сильно тормозит, то в вашем времени выполнения эти тормоза будут заметны очень сильно. аналогично -- все системные вызовы (Костя про это уже привёл пример).
OS вроде не по реальному времени пристреливает ваш скрипт.

я уже предлагал писать в лог записи с началом работы и завершением работы с uid-ами и подробностями (как минимум информацию о form), чтобы понять кто отваливается (ваше принудительное отваливание по времени предлагаю убрать).
в дополнение в лог можно добавить несколько точек кода с utime и stime и mem usage. лог лучше писать в csv виде, чтобы потом легко загрузить в БД (проще анализировать).

расскажите, наконец, используется-ли у вас hashfile или упомянутые мной редкозапускаемые процессы.
например, может быть такой кусок кода:

^if(^math:random(1000)<5){
	$hf[^hashfile::open[...]]
	^hf.cleanup[]
#	или, хуже:
#	^hf.foreach[;]{}
}

понятно, что в среднем каждый двухсотый запуск будет вызывать очистку хэшфайла. однако не каждая очистка может быть "фатальной". если перед очисткой приходит google bot, который "насрал" в hashfile, то она будет фатальной, если не приходил -- не будет.
т.е. код один (и корректный), параметры form одни, но условия всё равно могут быть сильно разные.

я пока в такие memory leak-и, которые из 6 МБ периодически на определённой площадке приводят к потреблению 100 МБ не верю. нет, я могу допустить, что такое возможно, но мне кажется, что вероятность других проблем гораздо выше.

ещё мысли в порядке бреда:
- попробовать другую сборку парсера
- попробовать собрать парсер на месте (и первое и второе в первую очередь ради GC, заодно попробовать друго GC)
- сделайте бинарнику strip (может OS получше будет относится к нему в плане кэширования)
- попробовать обновить парсер (у вас вроде был 3.4.1, можно попробовать 3.4.2 или текущий head)
- что у вас в $LIMITS.post_max_size?

---