pbxt-discuss team mailing list archive

[erkan yanar <erkan.yanar@xxxxxxxxxxxxx>]

Hi Paul,
(sorry for hijacking the thread)

On Sat, Oct 30, 2010 at 06:19:59PM +0200, Paul McCullagh wrote:
> 
> Also, writing an index is "all-or-nothing" so since about 20 GB of  
> index data is dirty it probably all has to be written.
> 
> Of course, as soon as one thread runs into this problem so do they all.
> 
> Normally this situation should be avoided...
> 

So is there a tip how to avoid these problem (with 1.0)?
Being still a noob about PBXT and I can't think about something else
than increasing pbxt_index_cache_size. Doing some testing comparing
massive parallel INSERTS (concurrency 8), the cache get filled faster
than maybe any single thread (sweeper?) could clean it.

I missed the function about ilog-1.xt. From the xtstat output it is correlated to
the indexfiles. But I missed the way it works (is configured) exactly. 

Is there a way to know if the Sweeper,Writer, etc. Threads are running?
As in my observations PBXT tends to stress the disks more than InnoDB.
So it would be nice to know what is doing the workload at that time.

On some tests all threads get stucked, which could be because of the
index-thing (mentioned in the quoted text) or something else. 

This leads me to a feature-assumption:)
I would like to have something like PBXT_TRX, PBXT_LOCKS etc. where we
could also see the Sweeper,Writer etc. threads.

Please excuse my silly questions, as I still claim the freedom of a noob:)

Best Regards
Erkan




-- 
über den grenzen muß die freiheit wohl wolkenlos sein