ilip a écrit 113 commentaires

  • [^] # Re: Script simplifié

    Posté par  . En réponse au message fuite mémoire PHP. Évalué à -1.

    je veux bien qu il garde des choses en mémoire, mais là garder le resultat d une requete sql qui fait 50MB, où est la limite ?
    je crois vraiment qu il s agit d un bug
    ou alors ce sont des buffers de communication entre postgresql et php ou entre php et apache qui ne sont pas libérés

  • [^] # Re: Script simplifié

    Posté par  . En réponse au message fuite mémoire PHP. Évalué à 1.

    Bonjour,

    C'est lorsque je rajoute la requête SQL que la mémoire utilisée passe à ~50MB.

    Pourtant il n'y a pas de fuite mémoire dans mon script PHP, j'apelle bien "pg_free_result" sur le résultat, le problème est ailleur.

    J'ai l'impression que PHP ne libère pas réellement les variables liées a postgresql.

    Peut être un problème au niveau du garbage collector.

  • [^] # Re: Script simplifié

    Posté par  . En réponse au message fuite mémoire PHP. Évalué à 1.

    Ok j'ai essayé MaxRequestsPerChild à 1 et ça fonctionne,

    Une fois la requête finie, le processus apache qui a géré la requête se ferme et donc la mémoire est libérée.

    Je trouve ça étonnant que apache même si apache garde ses processus fils ouverts pour être plus réactif, ceux-ci ne libèrent pas leur mémoire automatiquement.

    Cela m'entrainait des erreurs de type OOM :

    [ 8810.445983] postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
    [ 8810.455017] Backtrace:
    [ 8810.457611] [<c00416a8>] (dump_backtrace+0x0/0x110) from [<c03434d0>] (dump_stack+0x18/0x1c)
    [ 8810.466491]  r7:000201da r6:00000000 r5:de5af800 r4:0000006d
    [ 8810.472412] [<c03434b8>] (dump_stack+0x0/0x1c) from [<c00a5454>] (T.356+0x54/0x154)
    [ 8810.480407] [<c00a5400>] (T.356+0x0/0x154) from [<c00a5598>] (T.353+0x44/0x21c)
    [ 8810.488006]  r7:000201da r6:00000000 r5:de5af800 r4:0000006d
    [ 8810.493927] [<c00a5554>] (T.353+0x0/0x21c) from [<c00a59b8>] (out_of_memory+0x248/0x300)
    [ 8810.502380] [<c00a5770>] (out_of_memory+0x0/0x300) from [<c00a8a9c>] (__alloc_pages_nodemask+0x48c/0x57c)
    [ 8810.512359] [<c00a8610>] (__alloc_pages_nodemask+0x0/0x57c) from [<c00aa6bc>] (__do_page_cache_readahead+0xa8/0x1ec)
    [ 8810.523315] [<c00aa614>] (__do_page_cache_readahead+0x0/0x1ec) from [<c00aa828>] (ra_submit+0x28/0x30)
    [ 8810.533020] [<c00aa800>] (ra_submit+0x0/0x30) from [<c00a4250>] (filemap_fault+0x16c/0x3b4)
    [ 8810.541778] [<c00a40e4>] (filemap_fault+0x0/0x3b4) from [<c00b6fc8>] (__do_fault+0x58/0x3d4)
    [ 8810.550598] [<c00b6f70>] (__do_fault+0x0/0x3d4) from [<c00b8100>] (handle_mm_fault+0x304/0x678)
    [ 8810.559661] [<c00b7dfc>] (handle_mm_fault+0x0/0x678) from [<c0044b60>] (do_page_fault+0xe8/0x28c)
    [ 8810.568908] [<c0044a78>] (do_page_fault+0x0/0x28c) from [<c00322a4>] (do_DataAbort+0x3c/0xa0)
    [ 8810.577819] [<c0032268>] (do_DataAbort+0x0/0xa0) from [<c003d5e4>] (ret_from_exception+0x0/0x10)
    [ 8810.586944] Exception stack(0xdd9f9fb0 to 0xdd9f9ff8)
    [ 8810.592224] 9fa0:                                     40b11fd0 00000400 fffff166 40293f38
    [ 8810.600738] 9fc0: befbeedc befbf1fc 00000000 000000c7 befbf51c 403cc10c 00000000 40b12250
    [ 8810.609252] 9fe0: 00000000 befbee78 400f170d 400e1496 00000030 ffffffff
    [ 8810.616149]  r7:000000c7 r6:00000000 r5:befbf1fc r4:ffffffff
    [ 8810.622039] Mem-info:
    [ 8810.624420] Normal per-cpu:
    [ 8810.627319] CPU    0: hi:  186, btch:  31 usd:  31
    [ 8810.632324] active_anon:109444 inactive_anon:661 isolated_anon:0
    [ 8810.632324]  active_file:41 inactive_file:115 isolated_file:0
    [ 8810.632324]  unevictable:10146 dirty:0 writeback:0 unstable:0
    [ 8810.632324]  free:698 slab_reclaimable:592 slab_unreclaimable:1639
    [ 8810.632354]  mapped:8380 shmem:7141 pagetables:998 bounce:0
    [ 8810.662750] Normal free:2792kB min:2844kB low:3552kB high:4264kB active_anon:437776kB inactive_anon:2644kB active_file:164kB inactive_file:460kB unevictable:40584kB isolated(anon):0kB isolated(file):0kB present:505856kB mlocked:40584kB dirty:0kB writeback:0kB mapped:33520kB shmem:28564kB slab_reclaimable:2368kB slab_unreclaimable:6556kB kernel_stack:808kB pagetables:3992kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:953 all_unreclaimable? yes
    [ 8810.704620] lowmem_reserve[]: 0 0
    [ 8810.708068] Normal: 650*4kB 14*8kB 3*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2792kB
    [ 8810.718994] 8755 total pagecache pages
    [ 8810.722900] 0 pages in swap cache
    [ 8810.726348] Swap cache stats: add 0, delete 0, find 0/0
    [ 8810.731781] Free swap  = 0kB
    [ 8810.734771] Total swap = 0kB
    [ 8810.751281] 131072 pages of RAM
    [ 8810.754547] 986 free pages
    [ 8810.757385] 5877 reserved pages
    [ 8810.760650] 2231 slab pages
    [ 8810.763549] 78479 pages shared
    [ 8810.766723] 0 pages swap cached
    [ 8810.769989] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
    [ 8810.777709] [ 1566]     0  1566      572      214   0     -17         -1000 udevd
    [ 8810.785522] [ 2960]     0  2960     6876      273   0       0             0 rsyslogd
    [ 8810.793609] [ 3011]   103  3011     1069      159   0       0             0 dnsmasq
    [ 8810.801635] [ 3124]     0  3124      846      175   0       0             0 cron
    [ 8810.809356] [ 3161]   104  3161    11130     1527   0     -13          -900 postgres
    [ 8810.817443] [ 3169]   104  3169    11130     2385   0       0             0 postgres
    [ 8810.825531] [ 3170]   104  3170    11130      499   0       0             0 postgres
    [ 8810.833587] [ 3171]   104  3171    11130      452   0       0             0 postgres
    [ 8810.841644] [ 3172]   104  3172     3640      304   0       0             0 postgres
    [ 8810.849731] [ 3188]     0  3188     1521      216   0     -17         -1000 sshd
    [ 8810.857452] [ 3240]     0  3240      416      144   0       0             0 getty
    [ 8810.865234] [ 3242]     0  3242     2277      539   0       0             0 sshd
    [ 8810.872955] [ 3246]     0  3246      667      178   0       0             0 sftp-server
    [ 8810.881286] [ 3247]     0  3247     2277      540   0       0             0 sshd
    [ 8810.888977] [ 3255]     0  3255     1045      235   0       0             0 bash
    [ 8810.896697] [ 3269]     0  3269     2277      540   0       0             0 sshd
    [ 8810.904418] [ 3279]     0  3279     1085      243   0       0             0 bash
    [ 8810.912109] [ 3646]     0  3646     2277      540   0       0             0 sshd
    [ 8810.919830] [ 3658]     0  3658     1063      253   0       0             0 bash
    [ 8810.927551] [ 4568]     0  4568    10336    10146   0       0             0 acquisition
    [ 8810.935882] [ 4569]   104  4569    11451     1083   0       0             0 postgres
    [ 8810.943939] [ 4575]   104  4575    11451     1423   0       0             0 postgres
    [ 8810.952026] [ 4576]   104  4576    11195     2383   0       0             0 postgres
    [ 8810.960083] [ 4695]     0  4695     2277      540   0       0             0 sshd
    [ 8810.967803] [ 4709]     0  4709     1047      237   0       0             0 bash
    [ 8810.975494] [ 4839]     0  4839     1048      237   0       0             0 top
    [ 8810.983123] [ 5458]     0  5458     2277      540   0       0             0 sshd
    [ 8810.990844] [ 5466]     0  5466      700      184   0       0             0 sftp-server
    [ 8810.999176] [ 5825]     0  5825     5814     1236   0       0             0 apache2
    [ 8811.007141] [ 5844]    33  5844     6090     1487   0       0             0 apache2
    [ 8811.015136] [ 5845]    33  5845    12236     7625   0       0             0 apache2
    [ 8811.023101] [ 5846]    33  5846    12244     7598   0       0             0 apache2
    [ 8811.031097] [ 5847]    33  5847     8906     4222   0       0             0 apache2
    [ 8811.039062] [ 5848]    33  5848    18130    13666   0       0             0 apache2
    [ 8811.047058] [ 5849]   104  5849    11642     1548   0       0             0 postgres
    [ 8811.055145] [ 5851]   104  5851    11898     5538   0       0             0 postgres
    [ 8811.063232] [ 5852]    33  5852    18124    13645   0       0             0 apache2
    [ 8811.071197] [ 5853]    33  5853    18124    13648   0       0             0 apache2
    [ 8811.079193] [ 5858]    33  5858    18130    13651   0       0             0 apache2
    [ 8811.087158] [ 5859]   104  5859    11804     5511   0       0             0 postgres
    [ 8811.095275] [ 5860]   104  5860    11642     5287   0       0             0 postgres
    [ 8811.103363] [ 5861]   104  5861    11642     6979   0       0             0 postgres
    [ 8811.111419] [ 5862]    33  5862    18132    13652   0       0             0 apache2
    [ 8811.119415] [ 5863]    33  5863    18124    13645   0       0             0 apache2
    [ 8811.127380] [ 5870]   104  5870    11642     6728   0       0             0 postgres
    [ 8811.135437] [ 5900]   104  5900    11642     6921   0       0             0 postgres
    [ 8811.143524] [ 5994]   104  5994    11642     6925   0       0             0 postgres
    [ 8811.151580] [ 6674]   104  6674    11642     6972   0       0             0 postgres
    [ 8811.159667] [ 6689]   104  6689    11642     6918   0       0             0 postgres
    [ 8811.167724] [ 6753]     0  6753     1552      373   0       0             0 vim
    [ 8811.175354] Out of memory: Kill process 5848 (apache2) score 109 or sacrifice child
    [ 8811.183319] Killed process 5848 (apache2) total-vm:72520kB, anon-rss:53380kB, file-rss:1284kB
    [ 8967.585662] top invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
    [ 8967.594299] Backtrace:
    [ 8967.596893] [<c00416a8>] (dump_backtrace+0x0/0x110) from [<c03434d0>] (dump_stack+0x18/0x1c)
    [ 8967.605682]  r7:000201da r6:00000000 r5:dda30880 r4:0000008d
    [ 8967.611602] [<c03434b8>] (dump_stack+0x0/0x1c) from [<c00a5454>] (T.356+0x54/0x154)
    [ 8967.619598] [<c00a5400>] (T.356+0x0/0x154) from [<c00a5598>] (T.353+0x44/0x21c)
    [ 8967.627197]  r7:000201da r6:00000000 r5:dda30880 r4:0000008d
    [ 8967.633117] [<c00a5554>] (T.353+0x0/0x21c) from [<c00a59b8>] (out_of_memory+0x248/0x300)
    [ 8967.641571] [<c00a5770>] (out_of_memory+0x0/0x300) from [<c00a8a9c>] (__alloc_pages_nodemask+0x48c/0x57c)
    [ 8967.651519] [<c00a8610>] (__alloc_pages_nodemask+0x0/0x57c) from [<c00aa6bc>] (__do_page_cache_readahead+0xa8/0x1ec)
    [ 8967.662506] [<c00aa614>] (__do_page_cache_readahead+0x0/0x1ec) from [<c00aa828>] (ra_submit+0x28/0x30)
    [ 8967.672210] [<c00aa800>] (ra_submit+0x0/0x30) from [<c00a4250>] (filemap_fault+0x16c/0x3b4)
    [ 8967.680908] [<c00a40e4>] (filemap_fault+0x0/0x3b4) from [<c00b6fc8>] (__do_fault+0x58/0x3d4)
    [ 8967.689697] [<c00b6f70>] (__do_fault+0x0/0x3d4) from [<c00b8100>] (handle_mm_fault+0x304/0x678)
    [ 8967.698760] [<c00b7dfc>] (handle_mm_fault+0x0/0x678) from [<c0044b60>] (do_page_fault+0xe8/0x28c)
    [ 8967.708038] [<c0044a78>] (do_page_fault+0x0/0x28c) from [<c0032204>] (do_PrefetchAbort+0x3c/0xa0)
    [ 8967.717285] [<c00321c8>] (do_PrefetchAbort+0x0/0xa0) from [<c003d5e4>] (ret_from_exception+0x0/0x10)
    [ 8967.726806] Exception stack(0xde683fb0 to 0xde683ff8)
    [ 8967.732055] 3fa0:                                     000434c8 00920000 40299365 40118008
    [ 8967.740570] 3fc0: 0001fd80 00000000 bed689b4 0001e7dc 0001d628 0001d1a0 0001db90 0001d1a0
    [ 8967.749084] 3fe0: 4039c290 bed67ee0 0000e17f 0000e17e 20000030 ffffffff
    [ 8967.755981]  r7:0001e7dc r6:bed689b4 r5:00000000 r4:ffffffff
    [ 8967.761871] Mem-info:
    [ 8967.764251] Normal per-cpu:
    [ 8967.767150] CPU    0: hi:  186, btch:  31 usd:  46
    [ 8967.772155] active_anon:109550 inactive_anon:657 isolated_anon:0
    [ 8967.772155]  active_file:60 inactive_file:108 isolated_file:0
    [ 8967.772155]  unevictable:10146 dirty:0 writeback:0 unstable:0
    [ 8967.772186]  free:683 slab_reclaimable:584 slab_unreclaimable:1632
    [ 8967.772186]  mapped:8464 shmem:7141 pagetables:954 bounce:0
    [ 8967.802612] Normal free:2732kB min:2844kB low:3552kB high:4264kB active_anon:438200kB inactive_anon:2628kB active_file:240kB inactive_file:432kB unevictable:40584kB isolated(anon):0kB isolated(file):0kB present:505856kB mlocked:40584kB dirty:0kB writeback:0kB mapped:33856kB shmem:28564kB slab_reclaimable:2336kB slab_unreclaimable:6528kB kernel_stack:792kB pagetables:3816kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1018 all_unreclaimable? yes
    [ 8967.844573] lowmem_reserve[]: 0 0
    [ 8967.848022] Normal: 553*4kB 57*8kB 2*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2732kB
    [ 8967.858947] 8767 total pagecache pages
    [ 8967.862823] 0 pages in swap cache
    [ 8967.866302] Swap cache stats: add 0, delete 0, find 0/0
    [ 8967.871734] Free swap  = 0kB
    [ 8967.874725] Total swap = 0kB
    [ 8967.891204] 131072 pages of RAM
    [ 8967.894500] 978 free pages
    [ 8967.897338] 5877 reserved pages
    [ 8967.900604] 2216 slab pages
    [ 8967.903503] 72890 pages shared
    [ 8967.906677] 0 pages swap cached
    [ 8967.909942] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
    [ 8967.917694] [ 1566]     0  1566      572      214   0     -17         -1000 udevd
    [ 8967.925476] [ 2960]     0  2960     6876      275   0       0             0 rsyslogd
    [ 8967.933563] [ 3011]   103  3011     1069      159   0       0             0 dnsmasq
    [ 8967.941528] [ 3124]     0  3124      846      175   0       0             0 cron
    [ 8967.949249] [ 3161]   104  3161    11130     1527   0     -13          -900 postgres
    [ 8967.957305] [ 3169]   104  3169    11130     2384   0       0             0 postgres
    [ 8967.965393] [ 3170]   104  3170    11130      499   0       0             0 postgres
    [ 8967.973449] [ 3171]   104  3171    11130      460   0       0             0 postgres
    [ 8967.981536] [ 3172]   104  3172     3640      304   0       0             0 postgres
    [ 8967.989593] [ 3188]     0  3188     1521      216   0     -17         -1000 sshd
    [ 8967.997314] [ 3240]     0  3240      416      144   0       0             0 getty
    [ 8968.005096] [ 3242]     0  3242     2277      539   0       0             0 sshd
    [ 8968.012817] [ 3246]     0  3246      667      178   0       0             0 sftp-server
    [ 8968.021148] [ 3247]     0  3247     2277      540   0       0             0 sshd
    [ 8968.028869] [ 3255]     0  3255     1045      235   0       0             0 bash
    [ 8968.036560] [ 3269]     0  3269     2277      540   0       0             0 sshd
    [ 8968.044342] [ 3279]     0  3279     1085      243   0       0             0 bash
    [ 8968.052062] [ 3646]     0  3646     2277      540   0       0             0 sshd
    [ 8968.059783] [ 3658]     0  3658     1063      253   0       0             0 bash
    [ 8968.067474] [ 4568]     0  4568    10336    10146   0       0             0 acquisition
    [ 8968.075836] [ 4569]   104  4569    11451     1076   0       0             0 postgres
    [ 8968.083892] [ 4575]   104  4575    11451     1498   0       0             0 postgres
    [ 8968.091979] [ 4576]   104  4576    11195     2428   0       0             0 postgres
    [ 8968.100036] [ 4695]     0  4695     2277      540   0       0             0 sshd
    [ 8968.107727] [ 4709]     0  4709     1048      238   0       0             0 bash
    [ 8968.115447] [ 4839]     0  4839     1048      241   0       0             0 top
    [ 8968.123077] [ 5458]     0  5458     2277      540   0       0             0 sshd
    [ 8968.130767] [ 5466]     0  5466      700      184   0       0             0 sftp-server
    [ 8968.139129] [ 5825]     0  5825     5814     1236   0       0             0 apache2
    [ 8968.147094] [ 5844]    33  5844     6090     1487   0       0             0 apache2
    [ 8968.155090] [ 5845]    33  5845    12236     7625   0       0             0 apache2
    [ 8968.163055] [ 5846]    33  5846    22485    17722   0       0             0 apache2
    [ 8968.171051] [ 5847]    33  5847    12242     7597   0       0             0 apache2
    [ 8968.179016] [ 5849]   104  5849    11642     1543   0       0             0 postgres
    [ 8968.187103] [ 5851]   104  5851    11898     5525   0       0             0 postgres
    [ 8968.195159] [ 5852]    33  5852    18124    13645   0       0             0 apache2
    [ 8968.203155] [ 5853]    33  5853    18124    13648   0       0             0 apache2
    [ 8968.211120] [ 5858]    33  5858    18130    13651   0       0             0 apache2
    [ 8968.219146] [ 5859]   104  5859    11642     5376   0       0             0 postgres
    [ 8968.227233] [ 5860]   104  5860    11771     7303   0       0             0 postgres
    [ 8968.235290] [ 5862]    33  5862    18132    13652   0       0             0 apache2
    [ 8968.243286] [ 5863]    33  5863    18124    13645   0       0             0 apache2
    [ 8968.251251] [ 5870]   104  5870    11642     6719   0       0             0 postgres
    [ 8968.259338] [ 5900]   104  5900    11642     6907   0       0             0 postgres
    [ 8968.267395] [ 5994]   104  5994    11642     6915   0       0             0 postgres
    [ 8968.275482] [ 6674]   104  6674    11642     6960   0       0             0 postgres
    [ 8968.283538] [ 6689]   104  6689    11642     6904   0       0             0 postgres
    [ 8968.291595] [ 6773]     0  6773      748      102   0       0             0 tail
    [ 8968.299316] Out of memory: Kill process 5846 (apache2) score 141 or sacrifice child
    [ 8968.307281] Killed process 5846 (apache2) total-vm:89940kB, anon-rss:69604kB, file-rss:1284kB
    
    

    Merci pour ton aide

  • [^] # Re: Script simplifié

    Posté par  . En réponse au message fuite mémoire PHP. Évalué à 0.

    Le problème c'est que en une seule requête PHP le processus apache2 utilise 54MB de mémoire,

    Donc en 10 requête, j'arrive à 100% de mémoire utilisée, ma plateforme ARM en a 512MB.

    Le paramètre MaxMemFree (http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxmemfree) semble plus adapté, je l'ai reglé à 10000 (en KB), mais ça n'a pas résolu le problème.

    Exemple de consommation mémoire après 5 requêtes PHP :

    top - 11:15:22 up  2:15,  4 users,  load average: 1,50, 1,62, 1,64
    Tasks:  93 total,   1 running,  92 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  4,8 us,  0,0 sy,  0,0 ni, 95,2 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
    KiB Mem:    500780 total,   475860 used,    24920 free,     3196 buffers
    KiB Swap:        0 total,        0 used,        0 free,   120628 cached
    
      PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
     5844 www-data  20   0 24360 7204 2556 S   0,0  1,4   0:00.64 apache2
     5845 www-data  20   0 24360 7296 2604 S   0,0  1,5   0:00.62 apache2
     5846 www-data  20   0 24360 6976 2480 S   0,0  1,4   0:00.10 apache2
     5847 www-data  20   0 24360 6976 2480 S   0,0  1,4   0:00.10 apache2
     5848 www-data  20   0 24376 7020 2464 S   0,0  1,4   0:00.16 apache2
     5852 www-data  20   0 72496  54m 2536 S   0,0 11,1   0:20.42 apache2
     5853 www-data  20   0 72496  54m 2536 S   0,0 11,1   0:19.03 apache2
     5858 www-data  20   0 72520  54m 2536 S   0,0 11,2   0:06.34 apache2
     5862 www-data  20   0 72528  54m 2536 S   0,0 11,2   0:08.35 apache2
     5863 www-data  20   0 72496  54m 2536 S   0,0 11,1   0:19.00 apache2
    
    
  • [^] # Re: Script simplifié

    Posté par  . En réponse au message fuite mémoire PHP. Évalué à 1.

    J'ai testé le même site WEB sur le serveur Nginx, qui semble assez répandu et performant pour des fortes charges avec une consommation mémoire faible.

    Contrairement a apache2, la mémoire est bien libèrée après que le fichier ai été transmis au navigateur WEB :

    Avant execution script PHP :

      PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
     4404 www-data  20   0 20868 5716 2940 S   0,0  1,1   0:07.30 php5-cgi
     4919 www-data  20   0  8256 1316  492 S   0,0  0,3   0:00.00 nginx
    
    

    Pendant execution script PHP :

      PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
     4404 www-data  20   0 70340  53m 2940 R  56,9 10,9   0:14.97 php5-cgi
     4919 www-data  20   0  8256 1636  800 S  21,9  0,3   0:01.44 nginx
    
    

    Après execution script PHP :

      PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
     4404 www-data  20   0 20308 5260 2940 S   0,0  1,1   0:19.01 php5-cgi
     4919 www-data  20   0  8256 1636  800 S   0,0  0,3   0:03.09 nginx
    
    
  • # Script simplifié

    Posté par  . En réponse au message fuite mémoire PHP. Évalué à 1.

    J'ai simplifié au maximul mon script pour localiser l'erreur :

      /* HEADER TEXT */
      header('Content-Type: text/plain; charset: UTF-8');
      header('Content-Disposition: attachment; filename=test.csv');
    
      error_log('MEM USAGE 1 : '.memory_get_usage());
      (qui donne 149952 bytes)  
    
      for ($i=0; $i<200000; $i++)
      {
       for ($j=0; $j<15; $j++)
       {
        echo rand();
        echo ";";
       }
       echo "\n";
      }
    
      flush();
    
      error_log('MEM USAGE 2 : '.memory_get_usage());
      (qui donne 150072 bytes)
    
    

    Donc là pas de requête PostgreSQL, pas d'allocation en RAM, juste du "echo".

    Le fichier téléchargé fait 30MB

    A chaque fois que je lance la page sur un navigateur WEB et télécharge le fichier généré j'ai un nouveau processus apache2 qui utilise de la mémoire et qui ne termine jamais :

    top -d ,2 -U www-data :

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    3388 www-data 20 0 23384 5880 1728 S 0,0 1,2 0:57.44 apache2
    3389 www-data 20 0 23392 5884 1728 S 0,0 1,2 0:57.03 apache2
    3390 www-data 20 0 23392 5880 1732 S 0,0 1,2 0:29.83 apache2
    3392 www-data 20 0 23352 5840 1732 S 0,0 1,2 0:29.83 apache2
    3393 www-data 20 0 23384 5876 1728 S 0,0 1,2 1:43.94 apache2
    3396 www-data 20 0 23384 5872 1728 S 0,0 1,2 0:53.93 apache2

    Pourquoi ces processus ne se terminent pas ou ne libèrent pas leur mémoire ?

    D'après moi c'est une erreur du serveur apache

    Je testerai demain sur une Debian Squeeze au lieu de Wheezy

  • [^] # Re: marrant

    Posté par  . En réponse au message fuite mémoire PHP. Évalué à 1.

    Le code n'est pas complet, je n'ai mis que le code qui peut être utile à comprendre le problème.

    Dans le vrai code, le pg_free_result n'est pas dans la boucle while.

    J'ai fais un test en utilisant la fonction memory_get_usage en début et fin du script PHP, qui mesure la mémoire allouée par le script (http://php.net/manual/en/function.memory-get-usage.php).

    J'obtiens 161984 bytes au début et 165152 bytes à la fin.

    Donc apparement la mémoire RAM consommée par le processus apache ne vient pas de la mémoire allouée par le script PHP..

  • # script bash

    Posté par  . En réponse au message Cohérence de l'évolution des données. Évalué à 2.

    bonjour
    un script shell lancé periodiquement par cron avec des commandes SQL (psql) ferait l affaire ?

  • [^] # Re: /dev/ttyUSB0

    Posté par  . En réponse au message Règles UDEV. Évalué à 1.

    Ca ne marche pas non plus

  • [^] # Re: /dev/ttyUSB0

    Posté par  . En réponse au message Règles UDEV. Évalué à 1.

    Bonjour,

    Ca je l'ai déjà fait :

    root@debian:~# udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB2) 
    
    looking at device '/devices/platform/musb-omap2430.0/musb-hdrc.0/usb1/1-1/1-1.5/1-1.5.2/1-1.5.2:1.0/ttyUSB2/tty/ttyUSB2':
        KERNEL=="ttyUSB2"
        SUBSYSTEM=="tty"
        DRIVER==""
    
      looking at parent device '/devices/platform/musb-omap2430.0/musb-hdrc.0/usb1/1-1/1-1.5/1-1.5.2/1-1.5.2:1.0/ttyUSB2':
        KERNELS=="ttyUSB2"
        SUBSYSTEMS=="usb-serial"
        DRIVERS=="ftdi_sio"
        ...
    
      looking at parent device '/devices/platform/musb-omap2430.0/musb-hdrc.0/usb1/1-1/1-1.5/1-1.5.2/1-1.5.2:1.0':
        KERNELS=="1-1.5.2:1.0"
        SUBSYSTEMS=="usb"
        DRIVERS=="ftdi_sio"
        ...
    
      looking at parent device '/devices/platform/musb-omap2430.0/musb-hdrc.0/usb1/1-1/1-1.5/1-1.5.2':
        KERNELS=="1-1.5.2"
        SUBSYSTEMS=="usb"
        DRIVERS=="usb"
        ...
    
      looking at parent device '/devices/platform/musb-omap2430.0/musb-hdrc.0/usb1/1-1/1-1.5':
        KERNELS=="1-1.5"
        SUBSYSTEMS=="usb"
        DRIVERS=="usb"
        ...
    
      looking at parent device '/devices/platform/musb-omap2430.0/musb-hdrc.0/usb1/1-1':
        KERNELS=="1-1"
        SUBSYSTEMS=="usb"
        DRIVERS=="usb"
        ...
    
    looking at parent device '/devices/platform/musb-omap2430.0/musb-hdrc.0/usb1':
        KERNELS=="usb1"
        SUBSYSTEMS=="usb"
        DRIVERS=="usb"
        ...
    
      looking at parent device '/devices/platform/musb-omap2430.0/musb-hdrc.0':
        KERNELS=="musb-hdrc.0"
        SUBSYSTEMS=="platform"
        DRIVERS=="musb-hdrc"
        ...
    
    
    ...
    
    

    D'où la règle SUBSYSTEM=="tty", KERNELS=="1-1.5.2", SYMLINK+="ttyCOMIO1" qui aurait due marcher

  • [^] # Re: pas vraiment une solution mais

    Posté par  . En réponse au message Règles UDEV. Évalué à 1.

    Bonjour,

    Je n'ai pas trop le choix sur la version du noyau.

    Mon problême n'est au niveau driver USB-RS232, ça fonctionne bien en utilisant /dev/ttyUSB0, le problème est que je n'arrive pas à configurer les règles udev pour ajouter un lien symbolique /dev/ttyCOMIOX vers ce périphérique dont le chemin USB est 1-1.5.2 (il y'a 2 hubs USB en cascade avec 7 convertisseurs USB-RS232 connectés, il faut pouvoir les différencier).

    Je suppose que udev utilise les fichiers noyau de /sys pour identifier les périphériques (à confirmer), et c'est peut être là qu'il y'a eu une modification venant du noyau 2.6.37

    C'est assez spécial les rêgles udev et dur de trouver de la documentation détaillée.
    Lorsque l'on ajoute un 'S' au critères recherchés (KERNELS, SUBSYSTEMS …) c'est qu'on indique une propriété d'un parent du périphérique (dans mon cas un port USB).
    Mais il est précisé qu'on ne peut pas définir des propriétés de plusieurs parents différents.

    Donc d'après le udevadm info, la rêgle simple SUBSYSTEM=="tty", KERNELS=="1-1.5.2", SYMLINK+="ttyCOMIO1" devrait fonctionner, ce n'est pas le cas.

  • [^] # Re: GROUP BY

    Posté par  . En réponse au message Requêtes SQL. Évalué à 1.

    Bonjour,

    C'est bien ce que je cherchai a faire.

    Pour la première requête ça donne :

    SELECT s, COUNT(status) 
    FROM generate_series(0, 20, 1) AS s
    LEFT JOIN (
        SELECT status 
        FROM donnees
        WHERE timestamp >= 1104537600 
        AND timestamp < 1104624000
        ) d ON s=d.status
    GROUP BY s
    ORDER BY s;
    
    

    La requête sur 229398 lignes me renvoit bien les cumuls :

    0;218584
    1;527
    2;577
    3;557
    4;528
    5;552
    6;544
    7;549
    8;549
    9;566
    10;548
    11;528
    12;578
    13;506
    14;530
    15;540
    16;499
    17;540
    18;528
    19;532
    20;536

    La requête prend 6812 msec ce qui est assez performant.

    Avant j'obtenai le même résultat en faisant une requête COUNT pour chaque valeur de status :

    SELECT COUNT(status) 
        FROM donnees
        WHERE timestamp >= 1104537600 
        AND timestamp < 1104624000
        AND status=0;
    
    SELECT COUNT(status) 
        FROM donnees
        WHERE timestamp >= 1104537600 
        AND timestamp < 1104624000
        AND status=1;
    
    ...
    
    

    Ce qui me prenait 51802 msec

    Pour la deuxième requête par contre c'est moins bon au niveau performances et je ne comprend pas pourquoi :

    Je veux répartir la colonne "valeur" dans 15 intervalles différents :

    -∞ à -120
    -120 à -100
    -100 à -80
    -80 à -60
    -60 à -40
    -40 à -20
    -20 à 0
    0 à 20
    20 à 40
    40 à 60
    60 à 80
    80 à 100
    100 à 120
    120 à +∞

    Ma requête est:

    SELECT (s.values*20), COUNT(valeur)
    FROM (SELECT generate_series(-7, 7, 1) AS values) as s
    LEFT JOIN (
        SELECT valeur 
        FROM donnees_brutes 
        WHERE timestamp >= 1104537600 
        AND timestamp < 1104624000
        ) t ON ((t.valeur >= s.values*20) OR (s.values = -7)) AND ((t.valeur < ((s.values*20)+20)) OR (s.values = 7))
    GROUP BY s.values
    ORDER BY s.values;
    
    

    Comme la précédente requête, il y'a 229398 lignes, cela me renvoit :

    -∞;1090
    -120;2325
    -100;1169
    -80;3521
    -60;3437
    -40;17349
    -20;17269
    0;137523
    20;17308
    40;16870
    60;3466
    80;3397
    100;1166
    120;2311
    +∞;1197

    Mais j'ai ce résultat en 43875 msec.

    Alors que si je fais des requêtes COUNT pour chaque intervalles séparément, j'ai le résultat 37738 msec, ce qui est meilleur que la requête groupée.

  • [^] # Re: GROUP BY

    Posté par  . En réponse au message Requêtes SQL. Évalué à 1.

    L'équivalent de la requête avec la fonction generate_series est :

    SELECT
        s.status
      , COUNT(*)
    FROM
        (SELECT status FROM generate_series(0, 9, 1) AS status) s
    LEFT JOIN
         donnees d ON d.status=s.status
    GROUP BY 
        s.status
    ;
    
    
  • [^] # Re: GROUP BY

    Posté par  . En réponse au message Requêtes SQL. Évalué à 1.

    Bonjour,

    Pour la première requête, ça ne marche pas.

    Création des tables avec les valeurs :

    CREATE TABLE donnees
    (
      id bigserial NOT NULL,
      status smallint,
      valeur integer,
      CONSTRAINT donnees_pkey PRIMARY KEY (id )
    )
    
    INSERT INTO donnees (status, valeur) VALUES ('0', '30');
    INSERT INTO donnees (status, valeur) VALUES ('0', '65');
    INSERT INTO donnees (status, valeur) VALUES ('0', '20');
    INSERT INTO donnees (status, valeur) VALUES ('7', '25');
    INSERT INTO donnees (status, valeur) VALUES ('0', '25');
    
    CREATE TABLE status_list
    (
      id bigserial NOT NULL,
      status smallint,
      libelle text,
      CONSTRAINT status_list_pkey PRIMARY KEY (id )
    )
    
    INSERT INTO status_list (status, libelle) VALUES ('0', '--');
    INSERT INTO status_list (status, libelle) VALUES ('1', '--');
    INSERT INTO status_list (status, libelle) VALUES ('2', '--');
    INSERT INTO status_list (status, libelle) VALUES ('3', '--');
    INSERT INTO status_list (status, libelle) VALUES ('4', '--');
    INSERT INTO status_list (status, libelle) VALUES ('5', '--');
    INSERT INTO status_list (status, libelle) VALUES ('6', '--');
    INSERT INTO status_list (status, libelle) VALUES ('7', '--');
    INSERT INTO status_list (status, libelle) VALUES ('8', '--');
    INSERT INTO status_list (status, libelle) VALUES ('9', '--');
    
    

    La requête :

    SELECT
        s.status
      , COUNT(*)
    FROM
        status_list s
    LEFT JOIN
        donnees d ON d.status=s.status
    GROUP BY 
        s.status
    ;
    
    

    me renvoi :

    0;4
    1;1
    2;1
    3;1
    4;1
    5;1
    6;1
    7;1
    8;1
    9;1

  • [^] # Re: GROUP BY

    Posté par  . En réponse au message Requêtes SQL. Évalué à 0.

    Bonjour

    Cette requête fonctionne, j'obtiens :

    0;421
    3;4
    5;2
    6;2
    7;3
    8;1

    Mais il me faut une ligne pour chaque status :

    0;421
    1;0
    2;0
    3;4
    4;0
    5;2
    6;2
    7;3
    8;1
    9;0

    Et je pense qu'il y'a une solution avec generate_series(0, 10, 1)

  • [^] # Re: select count distinct

    Posté par  . En réponse au message Requêtes SQL. Évalué à -1.

    Bonjour,

    Ca ne correspond pas à ce que je veux.

    Lorsque j'exécute ces requêtes, le résultat est '10'

    Ca me compte combien de status différents j'ai dans ma table.

    Or ce que je veux c'est le nombre d'occurence pour chaque status différent dans la table.

  • # Re: Des autres approches

    Posté par  . En réponse au message Droits serveur PHP. Évalué à 0.

    Ok merci pour vos solutions, ça répond bien au problème

    La solution setuid(0) fonctionne, la solution sudo avec un script aussi,

    On peut aussi autoriser l'utilisateur www-data d'utiliser la commande kill avec sudo :

    apt-get install sudo

    vim /etc/sudoers.d/test :
    www-data ALL= NOPASSWD: /bin/kill

    code PHP :

    exec sudo kill -SIGTERM $pid

    Mais c'est peut être plus sécurisé de passer par un script intermédiare

  • [^] # Re: Des autres approches

    Posté par  . En réponse au message Droits serveur PHP. Évalué à 1.

    Bonjour,

    Mon programme doit être lancé avec d'avantages de droits que le user www-data

    Les sockets sont une solution mais c'est plus lourd à implémenter

    Il faut trouver comment autoriser le serveur PHP à envoyer des signaux à des programmes qui ne sont pas dans son groupe, ou créer un groupe supplémentaire, mais ça n'a pas l'air de marcher

  • # Essai avec un utilisateur à la place de root

    Posté par  . En réponse au message Droits serveur PHP. Évalué à -1.

    J'ai essayé quelque chose qui n'a pas marché :

    Création d'un utilisateur test :
    adduser test

    Ajout de "test" dans le groupe "www-data"
    et ajout de l'utilisateur "www-data" dans le groupe "test"

    /etc/group :

    www-data:x:33:test
    test:x:1000:www-data

    Je lance mon programme avec l'utilisateur "test"

    Mais ça me fait toujours "Operation not permitted"

  • [^] # Re: X11

    Posté par  . En réponse au message Lire une vidéo sur ARM avec Qt. Évalué à 0.

    par contre une question technique
    pour les architectures ARM, pourquoi est il necessaire de tout recompiler (Qt ou GStreamer par exemple) pour profiter de l'acceleration graphique d une puce, alors que c pas le cas pour des cartes graphiques normales (Radeon, Geforce …) ?

  • [^] # Re: X11

    Posté par  . En réponse au message Lire une vidéo sur ARM avec Qt. Évalué à 0.

    justement, dans ce cas X regle le probleme d'acces concurrent au framebuffer, en placant la video par dessus la fenetre Qt

  • [^] # Re: X11

    Posté par  . En réponse au message Lire une vidéo sur ARM avec Qt. Évalué à 1.

    Mais si par exemple Qt est compilé avec le support openGL ES de la puce graphique, sachant que c'est Qt qui dessine tout ses Widget / animations, alors Xorg n'a pas besoin d'accélération graphique ?

    Pareil par exemple pour GStreamer ?

    Xorg ne fait que fournir des framebuffers intermédiaires qu'il va ensuite superposer (role du compositeur) ?

  • [^] # Re: X11

    Posté par  . En réponse au message Lire une vidéo sur ARM avec Qt. Évalué à 1.

    C'est pas énorme non plus

    apt-get install -o APT::Install-Recommends=false" xserver-xorg-core xserver-xorg-video-fbdev xserver-xorg-input-evdev :

    Après cette opération, 12,8 Mo d'espace disque supplémentaires seront utilisés.

    apt-get install -o APT::Install-Recommends=false" libqtcore4 libqtgui4 :

    Après cette opération, 27,2 Mo d'espace disque supplémentaires seront utilisés.

    Après au niveau performances CPU et quantité RAM pour Xorg je sais pas trop

  • [^] # Re: Lire une vidéo sur ARM avec Qt

    Posté par  . En réponse au message Lire une vidéo sur ARM avec Qt. Évalué à 1.

    Ok,

    Moi je fais du développement sur des processeurs ARM Omap Cortex-A8 fréquence 1GHz, donc c'est suffisament performant pour faire tourner Xorg.

    Par contre pour économiser de la place je n'installe que les parties de Xorg qui me sont nécessaires.
    Sur Debian ça donne :

    /etc/apt/apt.conf :
    APT::Install-Recommends "false";

    apt-get install xserver-xorg-core xserver-xorg-video-fbdev xserver-xorg-input-evdev

    Ca évite d'installer tout les packages inutiles pour ma plateforme :
    xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-apm xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips xserver-xorg-video-cirrus xserver-xorg-video-i128 xserver-xorg-video-i740 xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-nv xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-rendition xserver-xorg-video-s3 xserver-xorg-video-s3virge xserver-xorg-video-savage xserver-xorg-video-siliconmotion xserver-xorg-video-sis xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-vesa xserver-xorg-video-voodoo
    (et leurs dépendances)

    Sinon j'avais testé à l'époque une version allégée du serveur Xorg pour démarrer plus rapidement : Xfbdev

    Mais je n'avais pas réussi a faire fonctionner une dalle tactile avec…

  • # X11

    Posté par  . En réponse au message Lire une vidéo sur ARM avec Qt. Évalué à 1.

    En passant par Xorg c'est facile, car les appli n'écrivent pas directement dans le framebuffer, et c'est Xorg qui s'occupe de placer la video par dessus le programme Qt.

    Quel est l'intérêt d'utiliser Qt en mode framebuffer ?