Subject: Re: [Firebird-devel] [FB-Tracker] Created:
(CORE-5419) Index garbage collection on varchar
column causes server to hang

On 01/11/17 20:36, Vlad Khorsun wrote:
> 11.01.2017 16:01, Alex Peshkoff wrote:
>> On 01/11/17 16:19, Vlad Khorsun wrote:
>>> 11.01.2017 15:09, Alex Peshkoff wrote:
>>>>>> Could you try fb2.5 (as i did) ?
>>>>> Will do.
>>>> On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdown
>>>> is present when 'delete from test' is executed.
>>> Slowdown of what operation ?
>>>> Nothing special for GC, but must say that master seems to miss even this
>>>> slowdown.
>>> Master is out of question ;)
>>>> Rather hard to say for sure cause execution time of test
>>>> connection varies from 0.01 sec to 0.02 sec for 2.5, not more. For
>>>> master it seems to be almost always 0.01.
>>> What is done in that test connection ? Could you try to create table
>>> and insert record into it ?
>> Run th following test:
>> for i in `seq 10000`; do echo IIIIIIII $i; time (echo 'create table tt(x
>> int); commit; insert into tt values(1); commit; drop table tt;'|./isql
>> todel.fdb) ; sleep 1; done
>> No activity - 0.8 - 0.9 sec
>> delete from test - 1.4 - 2.5 sec
>> select (with GC) - 1.9 - 3.8 sec
>> I.e. slowdown is obviously present but it's too far from being irresponsive.
> Thanks. Sad you can't reproduce it.

I remember that long ago linux had some problems with pthread_yield()
but already do not remember details, something like it did not cause
threads rescheduling. That definite...

ly violated posix requirements:
pthread_yield() causes the calling thread to relinquish the CPU, the
thread is placed at the _end_ of the run queue for its static priority
and another thread is scheduled to run.

I wonder - did you reproduce it on classic or superclassic?

> I do it easily. AST thread is blocked at
> Database::Sync::lock on syncMutex.enter() despite of a lot of checkouts in
> worker
> thread.

Hmm... From posix POV that's a bug but certainly windows calls may have
different rules. May be it makes sense to increase thread's priority
when it's going to deliver AST?

> Interesting is that debugger intrusion (just a breakpoint on THREAD_YIELD()
> at JRD_reschedule()) often helps AST thread to got control and unblock...

Not too strange.
Debugger certainly can in some way affect thread scheduling.

Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.
Firebird-Devel mailing list, web interface at

Programming list archiving by: Enterprise Git Hosting