Re: [firebird-support] Classic vs Superserver
On 29/08/2013 16:50, Leyne, Sean wrote: At the moment, SuperServer uses pseudo-threading, not true threading. What is pseudo-threading? This sounds like you are running into the automation database sweep, what is the sweep interval for the database? Turned off. -- Tim Ward [Non-text portions of this message have been removed]
Re: [firebird-support] Classic vs Superserver
On 29/08/2013 18:31, Alexandre Benson Smith wrote: Em 29/8/2013 12:17, Tim Ward escreveu: But I thought Superserver used threads? And threads can run on separate CPUs? (Processes are an address space thing, not a CPU thing.) There are threads, but in fact they are serialized, perhaps it's just an over simplification, I don't know FB internals, but the threads does not run in parallel (FB 3.0 will fix that). If you have a multi core server (wich is an obvious thing theses days) you should prefer Classic Server, the only case where I think SuperServer will be a choice is when you have just one connection per database. So Superserver is in effect single threaded and will use only a fraction of the power of even one of today's modest desktop PCs let alone a server - thanks, this wasn't obvious to me from the documentation. Perhaps you have automatic sweep disabled (check with gstat -h), if you have sweep disabled the garbage will acumulate, so when a query need to scan the table it will pay the cost to clean it up. I am not saying to use automatic sweep, since it could trigger in the middle of the day generating an unknown slowdown... What I suggest is that you keep automatic sweep disabled and run a manual sweep (gfix -sweep) during off peak hours. Automatic sweep is indeed disabled, but manual sweep during off peak hours isn't practical. The system can need to run flat out for a couple of days at a time, and the problem arises after only a few hours. -- Tim Ward [Non-text portions of this message have been removed]
RE: [firebird-support] Classic vs Superserver
we sometimes get queries, that normally complete in reasonable time, taking many times as long This sounds like you are running into the automation database sweep, what is the sweep interval for the database? Turned off. Hmm, do the queries suddenly or gradually drop performancewise? If gradually, it could be a problem with one or more long-running transactions. If suddenly (and repeatedly) it could be a) that Firebird (incorrectly) thinks another plan would be better b) running under a WAIT transaction if you're trying to update something that (an)other person(s) has changed but not committed yet These are at least a few possibilities, there could be others. Set
RE: [firebird-support] Classic vs Superserver
Tim, We're currently running Classic, and I'm looking into the possibility of switching to Superserver for the following reasons: (1) Garbage collection - we sometimes get queries, that normally complete in reasonable time, taking many times as long, and one possible explanation is garbage collection. We understand that Superserver has a background GC thread, so the chances of a two second user operation being randomly delayed by minutes can be reduced or eliminated. (2) Cache size. With frequent operations on a particular table occupying around 1,500 pages the cache size of 150 that we're currently using is believed to limit performance. So some questions: (3) Do these motivations make sense? Yes and no. ;-] Classic does not provide the fastest performance, but it does provide the most consistent multi-connection performance. It is currently (v3 will be changing this) the only engine which truly scales across CPUs. Garbage Collection is performed actively, but if you have good transaction management, the real overhead is not that bad. The biggest cost of Garbage Collection is that it generates disk writes, which will need to go to disk, which is a slow process. A good disk controller cache with protected write-back cache will eliminate that cost. Cache is and isn't a limitation, yes the engine will need to go to the OS for pages not in FB cache. With a reasonable amount of RAM in your server, however, the OS itself will have most 'hot' database pages cached, so you will not actually be going to disk to get the data. Here the faster the media, the lower the cost of the reads will be. Sean
Re: [firebird-support] Classic vs Superserver
Em 29/8/2013 12:17, Tim Ward escreveu: But I thought Superserver used threads? And threads can run on separate CPUs? (Processes are an address space thing, not a CPU thing.) There are threads, but in fact they are serialized, perhaps it's just an over simplification, I don't know FB internals, but the threads does not run in parallel (FB 3.0 will fix that). If you have a multi core server (wich is an obvious thing theses days) you should prefer Classic Server, the only case where I think SuperServer will be a choice is when you have just one connection per database. Perhaps you have automatic sweep disabled (check with gstat -h), if you have sweep disabled the garbage will acumulate, so when a query need to scan the table it will pay the cost to clean it up. I am not saying to use automatic sweep, since it could trigger in the middle of the day generating an unknown slowdown... What I suggest is that you keep automatic sweep disabled and run a manual sweep (gfix -sweep) during off peak hours. I will not worry about the shared cache, the file system cache will do almost the same as the shared cacee in SS will do, you will have a small memory overhead because of the separed caches for each connection, even if will set default cache to 1000 you will have 8MB or 16MB of cache duplication per connection, not that much... see you !
RE: [firebird-support] Classic vs Superserver
Alexandre, I will not worry about the shared cache, the file system cache will do almost the same as the shared cacee in SS will do, you will have a small memory overhead because of the separed caches for each connection, even if will set default cache to 1000 you will have 8MB or 16MB of cache duplication per connection, not that much... The only problem is that a large number (I would call 1000 a large number) of cache pages adds a significant load on the lock manager (which can be a contention point). A 'small' number for the cache size is recommended (personally, I would say between 75 and 300 pages) and leave the rest for the OS cache purposes. Sean
