No ths is not related to subject, this is another issue. I have few such reports from customers but without test case to reproduce it. I suspect this is related to garbage collection of a very long versions chain (ten's backversions for the same record). gstat -r could confirm it.
Regards, Vlad ---In firebird-support@yahoogroups.com, <abaddon@...> wrote : Also, possibly related to this (appears on same production servers) - sometimes all fb_inet_server.exe processes stop any disk i/o activity and wait for one process, which eats 100% of one CPU core. Stack trace for hung thread look like this: fb_inet_server!down_grade+0x145 fb_inet_server!down_grade+0x156 ....tens of recursive down_grade calls fb_inet_server!down_grade+0x156 fb_inet_server!blocking_ast_bdb+0x69 fb_inet_server!Jrd::LockManager::blocking_action+0x170 fb_inet_server!Jrd::LockManager::blocking_action_thread+0x11f fb_inet_server!Jrd::LockManager::blocking_action_thread+0x9 fb_inet_server!`anonymous namespace'::threadStart+0x55 msvcr80!_endthreadex+0x3b msvcr80!_endthreadex+0xc7 kernel32!BaseThreadInitThunk+0xe ntdll_77770000!__RtlUserThreadStart+0x23 ntdll_77770000!_RtlUserThreadStart+0x1b I has debug dump and lock print for hung process.
