Mysql
 sql >> Base de données >  >> RDS >> Mysql

BLOCAGE APPARENT Création de threads d'urgence pour les tâches en attente non affectées

Depuis http://www.mchange.com/projects/c3p0/#other_ds_configuration

numHelperThreads et maxAdministrativeTaskTime help pour configurer le comportement des pools de threads DataSource. Par défaut, chaque DataSource n'a que trois threads d'assistance associés. Si les performances semblent ralentir sous une charge importante, ou si vous observez via JMX ou une inspection directe d'un PooledDataSource, que le nombre de "tâches en attente" est généralement supérieur à zéro, essayez d'augmenter numHelperThreads. maxAdministrativeTaskTime peut être utile pour les utilisateurs confrontés à des tâches qui se bloquent indéfiniment et aux messages "APPARENT DEADLOCK". (Voir l'annexe A pour plus d'informations.)

maxAdministrativeTaskTime Par défaut :0 secondes avant que le pool de threads de c3p0 ne tente d'interrompre une tâche apparemment bloquée. Rarement utile. De nombreuses fonctions de c3p0 ne sont pas exécutées par des threads clients, mais de manière asynchrone par un pool de threads interne. L'asynchronisme de c3p0 améliore directement les performances du client et minimise la durée pendant laquelle les verrous critiques sont maintenus en garantissant que les opérations jdbc lentes sont effectuées dans des threads sans verrouillage. Si, toutefois, certaines de ces tâches "se bloquent", c'est-à-dire qu'elles ne réussissent ni n'échouent avec une exception pendant une période prolongée, le pool de threads de c3p0 peut être épuisé et les tâches administratives sauvegardées. Si les tâches sont simplement lentes, la meilleure façon de résoudre le problème est d'augmenter le nombre de threads, via numHelperThreads . Mais si les tâches se bloquent parfois indéfiniment, vous pouvez utiliser ce paramètre pour forcer un appel à la méthode interrupt() du thread de tâche si une tâche dépasse une limite de temps définie. [c3p0 finira par récupérer des tâches bloquées de toute façon en signalant un "APPARENT DEADLOCK" (vous le verrez comme un avertissement dans les journaux), en remplaçant les threads de tâche du pool de threads et en interrompant () les threads d'origine. Mais laisser le pool entrer dans une impasse APPARENTE puis récupérer signifie que pendant certaines périodes, les performances de c3p0 seront altérées. Donc, si vous voyez ces messages, l'augmentation de numHelperThreads et la définition de maxAdministrativeTaskTime peuvent aider . maxAdministrativeTaskTime doit être suffisamment grand pour que toute tentative raisonnable d'acquérir une connexion à partir de la base de données, de tester une connexion, ou de détruire une connexion, soit susceptible de réussir ou d'échouer dans le délai imparti. Zéro (valeur par défaut) signifie que les tâches ne sont jamais interrompues, ce qui est la politique la meilleure et la plus sûre dans la plupart des circonstances. Si les tâches sont simplement lentes, allouez plus de threads. Si les tâches sont suspendues pour toujours, essayez de comprendre pourquoi, et peut-être que la définition de maxAdministrativeTaskTime peut vous aider en attendant.

The default is 3 for numHelperThreads , increase this to 8-10 

setting maxAdministrativeTaskTime will help