Vous n'êtes pas identifié(e).
Pages : 1
Merci.
si on prend sur le wiki , l'exemple In Buffer Test : 0.1 * RAM = 0.1 * 2 = 0.2, cela fait effectivement un scale factor de 15 ( 0.2 * 75)
si on prend sur le wiki , l'exemple Mostly Cached : 0.9 * RAM = 0.9 * 2 = 1.8, cela donne un scale factor de 135 (1.8*75) ce qui ne correspond pas au scale indiqué de 70
si on prend sur le wiki , l'exemple Mostly on Disk : 4 * RAM = 4 * 2 = 8, cela fait effectivement un scale factor de 600 ( 8 * 75)
Je pense donc que l'exemple Mostly Cached est erroné.
Christian
Bonjour.
Sur la page : https://wiki.postgresql.org/wiki/Pgbenchtesting, je ne comprends pas les lignes suivantes et comment appliquer ces 2 formules en fonction de la RAM du serveur (dédié) et du niveau de performance souhaité (dans le shared_buffers, dans le cache , sur disque) pour savoir quel scale factor appliqué :
scale / 75 = 1GB database
In Buffer Test: 0.1 X RAM
Mostly Cached: 0.9 X RAM
Mostly on Disk: 4.0 X RAM
J'ai bien étudié les 3 exemples qu'ils donnent avec les 3 scales factor s = 15, s= 70, s= 600 mais je ne comprends comment ils arrivent à choisir ces scales factor.
Si on prends le cas du niveau de performance "sur disque) :
on a la formule : 4.0* RAM : est ce que c'est la taille cible de la base que l'on doit avoir ? donc pour un serveur (dédié) avec 8 Go de RAM : il faut que la base fasse 4 * 8 GB = 32 GB ? si oui, comment calculer le scale factor à donner à pgbench ?
Merci pour vos réponses éclairée qui me permettront de calculer les bons scales factor en fonction de la RAM et du niveau de perf à tester?
Cordialement,
Christian
Bonjour.
Quelques investigations supplémentaires m'ont mené à constater les choses suivantes :
- le process est en état S
- un kill -15 n'y fait rien
- le process est bloqué dans l'appel system : sendto
Je pense que le client (jdbc) a initié une requête et qu'il ne lit pas les résultats, ou que le close n'est pas fait sur le résultset. La requête ramenant suffisamment de données, postgres écrit dans le socket et fini par remplir les buffer TCP qui ne sont pas vidés par le client , d'où le blocage. En tuant le process java côté client, cela décoince bien le process côté postgres.
Questions :
- est-ce qu'un statement_timeout pourrait m'aider (j'en doute vu que mon kill -15 ne marche pas) ?
- y-a-t-il un moyen de positionner un timeout sur le read et sur le write du socket côté postgres (l'équivalent du setsockopt). Je n'ai rien trouvé dans ce sens dans postgresql.conf ?
Bonjour.
Il est possible effectivement que les données soient déjà dans le cache. Il faudrait que je re-teste cela sur de la la recette.
Par contre en ré-examinant les logs (on ne regarde jamais assez les logs :-( ) j'ai trouvé un message d'erreur très interessant :
"stack depth limit exceeded" sur un process dont la requête durait depuis des heures. Après vérification du status de ce process (ps -efl) ce dernier était en S (Interruptible sleep). J'ai donc modifié max_stack_depth. Je me pose toutefois la question : ok, la requête a fait exploser la pile, postgres le détecte bien (puisqu'il l'indique dans ses logs), mais pourquoi le process reste-t-il ? Même en état S, à priori les verrous sont toujours là ce qui est bloquant pour les autres requêtes. dans tous les cas j'attends que cela se reproduise pour aller un peu plus loin dans l'analyse.
Bonjour.
ok. Je vérifierai cela la prochaine fois.
Merci
Bonjour.
Régulièrement, j'ai des requêtes que je suis dans l'impossibilité de tuer. elles consomment de la CPU, et peuvent durer jusqu'à plusieurs jours.
un kill -INT ou un kill -15 ou un pg_cancel_backend ou un pg_terminate_backend n'y font rien. Les seules solutions que j'ai pu trouver c'est soit un kill -9 en espèrant que postgres sorte du recovery mode ou un stop/start. A noter quand je fais un stop/start, posgres inscrit dans les logs la requête toute entière : ce qui me permet de la rejouer dans pg_admin ou psql sans problème dans la majorité des cas.
Mon environnement :
Postgres 9.1.4 RHEL 5 64 bits.
J'ai épluché les releases notes de la 9.1 sans trouver quelque chose (mais je suis peut-être passé à côté).
Voici un exemple de requête que j'ai dû arrêter par start/stop postgres (elle tournait depuis 2h48', alors que dans pgadmin elle met 4 secondes) :
Par ailleurs il semble que ce soit lié à l'opérateur IN (tout du moins à chaque fois que j'ai le problème, la requête utilise IN)
SELECT B.MBUL , B.MMODEL , B.PVER , B.DFIN , R.* FROM RBULLETIN B , RRUB R WHERE B.MBUL IN ( 'AVIS_25264_2012-07_4' , 'AVIS_25209_2013-01_2' , 'AVIS_21904_2012-08_1' , 'AVIS_26036_2013-03_6' , 'AVIS_25795_2012-08_13' , 'AVIS_24101_2012-09_2' , 'AVIS_26043_2012-11_1' , 'AVIS_26578_2012-07_17' , 'AVIS_26849_2013-01_2' , 'AVIS_26564_2012-07_3' , 'AVIS_24985_2013-05_5' , 'AVIS_24767_2012-10_2' , 'AVIS_26827_2012-10_8' , 'AVIS_25017_2012-06_1' , 'AVIS_25017_2012-07_1' , 'AVIS_25017_2012-08_1' , 'AVIS_25017_2012-09_1' , 'AVIS_25017_2012-10_1' , 'AVIS_25017_2012-11_1' , 'AVIS_25017_2012-12_1' , 'AVIS_25017_2013-01_1' , 'AVIS_25017_2013-02_1' , 'AVIS_25017_2013-03_1' , 'AVIS_25017_2013-04_1' , 'AVIS_25017_2013-05_1' , 'AVIS_25793_2012-09_3' , 'AVIS_26140_2012-10_3' , 'AVIS_25942_2012-10_1' , 'AVIS_21739_2012-08_1' , 'AVIS_25160_2012-06_1' , 'AVIS_25160_2012-07_1' , 'AVIS_25160_2012-08_1' , 'AVIS_25160_2012-09_1' , 'AVIS_25160_2012-10_1' , 'AVIS_25160_2012-11_1' , 'AVIS_25160_2012-12_1' , 'AVIS_25160_2013-01_1' , 'AVIS_25160_2013-02_1' , 'AVIS_25160_2013-03_1' , 'AVIS_25160_2013-04_1' , 'AVIS_25160_2013-05_1' , 'AVIS_26681_2012-08_2' , 'AVIS_26673_2012-07_6' , 'AVIS_26517_2012-08_2' , 'AVIS_26972_2013-04_2' , 'AVIS_24821_2012-08_14' , 'AVIS_24862_2012-11_9' , 'AVIS_25300_2012-06_1' , 'AVIS_25300_2012-07_1' , 'AVIS_25300_2012-08_1' , 'AVIS_25300_2012-09_1' , 'AVIS_25300_2012-10_1' , 'AVIS_25300_2012-11_1' , 'AVIS_25300_2012-12_1' , 'AVIS_25300_2013-01_1' , 'AVIS_25300_2013-02_1' , 'AVIS_25300_2013-03_1' , 'AVIS_25300_2013-04_1' , 'AVIS_25300_2013-05_1' , 'AVIS_25488_2012-07_2' , 'AVIS_24101_2012-12_6' , 'AVIS_26589_2012-10_1' , 'AVIS_26742_2012-08_1' , 'AVIS_25232_2012-12_6' , 'AVIS_26217_2012-06_1' , 'AVIS_26217_2012-07_1' , 'AVIS_26217_2012-08_1' , 'AVIS_26217_2012-09_1' , 'AVIS_26217_2012-10_1' , 'AVIS_26217_2012-11_1' , 'AVIS_26217_2012-12_1' , 'AVIS_26217_2013-01_1' , 'AVIS_26217_2013-02_1' , 'AVIS_26217_2013-03_1' , 'AVIS_26217_2013-04_1' , 'AVIS_26217_2013-05_1' , 'AVIS_21573_2012-08_7' , 'AVIS_25598_2012-12_3' , 'AVIS_24812_2012-07_10' , 'AVIS_26761_2013-05_12' , 'AVIS_19059_2012-08_8' , 'AVIS_25917_2012-10_9' , 'AVIS_19007_2012-11_1' , 'AVIS_25694_2012-07_6' , 'AVIS_26822_2012-11_18' , 'AVIS_25562_2013-04_9' , 'AVIS_26702_2012-12_8' , 'AVIS_24020_2012-11_7' , 'AVIS_23746_2012-10_4' , 'AVIS_24812_2012-10_2' , 'AVIS_26704_2012-09_2' , 'AVIS_25443_2013-03_3' , 'AVIS_26254_2013-02_7' , 'AVIS_25922_2012-10_9' , 'AVIS_23219_2012-08_7' , 'AVIS_27011_2013-05_3' , 'AVIS_26254_2012-10_5' , 'AVIS_26760_2012-11_1' , 'AVIS_23639_2012-06_1' , 'AVIS_23639_2012-07_1' ) AND R.MBUL = B.MBUL AND R.RUNID = B.RUNID;
Si quelqu'un avait une idée ou un lien qui expliquerait ce problème peut-être connu .....
Merci
Pages : 1
