web2py reste bloqué et ne répond plus
cf. mon message d'hier sur la tâche « Avoir une méthode non bloquante pour 'compare patient' » : Serait-ce plus général ? Il y a en ce moment uwsgi qui tourne à 80% et mysql à 15% (depuis une dizaine de minutes) et rbx est complètement bloqué. J'ai lancé plusieurs Vidjil d'affilée mais rien d'autre sur le serveur. dev.vidjil.org continue à répondre.
uptime robot nous dit que rbx/web2py est resté dans les choux mercredi 15/04 entre 18h01 et 18h10 puis entre 18h16 et 18h30 (j'avais lancé plusieurs vidjil). Les requêtes que j'avais lancé (accéder à la page patients) sont visiblement restées bloquées sur le serveur et ont été exécutées à 18h30 (je n'étais plus au bureau, mon ordinateur était déconnecté). Mais il ne s'est rien passé entre 18h20 et 18h30… [19664] 2015-04-15 18:20:34,535 INFO - task.py:313 None [2657] c26: 'fuse' finished - /mnt/result/tmp/out-002657//002657.fused [19115] 2015-04-15 18:30:33,890 DEBUG - patient.py:411 134.206.10.234/team/LIFL <Mikaël> patient list (0.366s) [19116] 2015-04-15 18:30:33,950 DEBUG - db.py:242 Creating logger [19114] 2015-04-15 18:30:34,092 DEBUG - db.py:242 Creating logger [19115] 2015-04-15 18:30:34,291 DEBUG - default.py:221 134.206.11.64/team/LIFL get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused [19116] 2015-04-15 18:30:34,415 DEBUG - default.py:221 134.206.11.64/team/LIFL get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused [20576] 2015-04-15 18:30:34,538 DEBUG - db.py:242 Creating logger [20572] 2015-04-15 18:30:34,579 DEBUG - db.py:242 Creating logger [20574] 2015-04-15 18:30:34,658 DEBUG - db.py:242 Creating logger [19114] 2015-04-15 18:30:34,679 DEBUG - patient.py:411 134.206.10.234/team/LIFL <Mikaël> patient list (0.558s) [20574] 2015-04-15 18:30:34,802 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (394) [19115] 2015-04-15 18:30:34,911 DEBUG - patient.py:411 134.206.11.64/team/LIFL patient list (0.438s) [19117] 2015-04-15 18:30:35,235 DEBUG - patient.py:411 134.206.10.234/team/LIFL <Mikaël> patient list (0.329s) [19057] 2015-04-15 18:30:35,451 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused [19114] 2015-04-15 18:30:35,669 DEBUG - patient.py:411 134.206.11.64/team/LIFL patient list (0.482s) [19057] 2015-04-15 18:30:35,799 DEBUG - default.py:221 134.206.11.64/team/LIFL get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused [19057] 2015-04-15 18:30:36,165 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (474)
Ce matin, rebelote, je visualise plusieurs patients de Fred et rbx/web2py est de nouveau dans les choux. Pendant ce temps dev.vidjil.org répond (c'est donc juste l'instance web2py qui rame, ce n'est pas le serveur physique). Même chose que hier uwsgi est ~85% et mysql ~15% du CPU
Reproduit sous dev. À partir des log on peut voir que la consultation ne posait pas problème mais ce qui posait problème ce sont les get_data apparemment. Visiblement web2py n'était pas complètement bloqué puisqu'il continuait à faire des « Creating logger » dans db.py toutes les 20 minutes : [19112] 2015-04-16 17:50:46,357 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (435) [19112] 2015-04-16 17:50:46,483 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (435) [19112] 2015-04-16 17:50:46,778 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (436) [19112] 2015-04-16 17:50:47,263 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (437) [19112] 2015-04-16 17:50:47,667 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (438) [19112] 2015-04-16 17:50:48,342 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (439) [19112] 2015-04-16 17:50:48,952 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (440) [2250] 2015-04-16 18:10:51,326 DEBUG - db.py:242 Creating logger [3624] 2015-04-16 18:30:53,367 DEBUG - db.py:242 Creating logger [5082] 2015-04-16 18:50:55,571 DEBUG - db.py:242 Creating logger [6679] 2015-04-16 19:10:57,785 DEBUG - db.py:242 Creating logger [8030] 2015-04-16 19:30:59,971 DEBUG - db.py:242 Creating logger [9394] 2015-04-16 19:51:01,214 DEBUG - db.py:242 Creating logger [11057] 2015-04-16 20:11:03,395 DEBUG - db.py:242 Creating logger [12409] 2015-04-16 20:31:05,566 DEBUG - db.py:242 Creating logger [13773] 2015-04-16 20:51:08,579 DEBUG - db.py:242 Creating logger [15375] 2015-04-16 21:11:09,977 DEBUG - db.py:242 Creating logger [16730] 2015-04-16 21:31:11,276 DEBUG - db.py:242 Creating logger [18096] 2015-04-16 21:51:13,396 DEBUG - db.py:242 Creating logger [19711] 2015-04-16 22:11:15,589 DEBUG - db.py:242 Creating logger [21074] 2015-04-16 22:31:17,812 DEBUG - db.py:242 Creating logger [22440] 2015-04-16 22:51:20,011 DEBUG - db.py:242 Creating logger [24037] 2015-04-16 23:11:21,230 DEBUG - db.py:242 Creating logger [24037] 2015-04-16 23:11:21,339 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused [24037] 2015-04-16 23:11:21,447 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c1 -> /mnt/result/results-dev//fused_file.fused_file.9fecdb93375410bd.3030323236312e6675736564.fused [24037] 2015-04-16 23:11:21,523 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused [24037] 2015-04-16 23:11:21,591 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused [24037] 2015-04-16 23:11:21,661 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused [24037] 2015-04-16 23:11:21,729 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused [24037] 2015-04-16 23:11:21,810 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c1 -> /mnt/result/results-dev//fused_file.fused_file.9fecdb93375410bd.3030323236312e6675736564.fused
Mais charger plein de data d'un coup ne semble pas lui poser problème. En revanche ce qui semble poser problème c'est bourriner le lien « prev » (sur une fiche patient) alors qu'on est déjà au bout.
Ah ben oui… while db.patient[new_id] is None and int(new_id) > 0: new_id = str(int(new_id)+int(request.vars["next"])) Une jolie boucle infinie (next > 0)
merci et désolé :)