On 16.06.2011 19:29, Daniel P. Berrange wrote: > On Thu, Jun 16, 2011 at 04:29:55PM +0200, Michal Privoznik wrote: >> Up to now, we've created new worker threads only during new connection. >> This patch monitors worker threads for liveness and dynamically create >> new one if all are stuck, waiting for hypervisor to reply. This >> situation can happen. All one need to do is send STOP signal to qemu. >> The amount of time when we evaluate thread as stuck is defined in >> WORKER_TIMEOUT macro. >> >> With this approach we don't need to create new worker thread on incoming >> connection. However, as number of active worker threads grows, it might >> happen we need to size up the pool of worker threads and hence exceed >> the max_worker configuration value. > > This is really not desirable. The max_workers limit is in the > configuration as a static limit, to prevent client applications > from making libvirtd spawn an unlimited number of threads. We > must *always* respect the max_workers limit. > > I don't think automatically spawning workers is the right way > to deal with the QEMU issue anyway. As mentioned before, we need > to improve the QEMU monitor driver so that we can safely allow > monitor commands to time out > > Regards, > Daniel Well, and what about compromise. Don't exceed the max_workers limit, but possibly create workers on API calls instead only on new connection? Even with timeouts on qemu monitor we can be unresponsive for min(QEMU_JOB_WAIT_TIME, monitor_timeout) even without obvious reason. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list