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 ?