On Thu 16 Nov 2006 18:13, Sven Anderson wrote: > Hi all, > > Paolo Lucente, 16.11.2006 02:03: > > Now, back to our syncronous approach: what was killing it was the > > excessive slowness the database and the concurrent arrival of packets at > > very high rates. Keeping the two entities (network and DB) asyncronous, > > segregated, gave a big relief and better performances (under normal > > conditions). Things that were requiring to be written down at the time > > were: a way to establish a kind of normal database behaviour in order to > > promptly react to excessive slowness, how the process can understand when > > to give up (pretty variable) and, of course, how to react, ie. what to do > > if data continue to accumulate. > > of course separation of metering and DB access is a good thing. But I > think what Chris is suggesting is to have the write-to-DB jobs queued in > one single writer thread rather than creating a new thread for each job. I > also have the feeling this might be more effective, but it's just a > feeling, I have no clue how much new resources an additional thread really > needs.
Yes. This is also something I have been suggesting for some time. Basically on a single CPU, single DISK database server ONE or at most TWO database threads will be fastest.. If you have more CPUs and DISKs then it MAY make sense to increase the number of DB threads depending on which DB system you use AND which locking scheme... > Of course, if the data is coming too fast for the DB, it is to fast, no > matter how the writer is organized. But if you use more resources for > other stuff (like creating new threats) you might reach this limit earlier. This is a given... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
