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 definitely 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. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
