Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Probleme memoire

22 réponses
Avatar
Jean-Francois Ortolo
Bonjour

Je suis en train de terminer un script PHP, assez gros.

Voici les dimensions approximatives:

longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo
par script ), suffira pour qu'il n'y ait pas d'erreur par manque de
mémoire allouée ?

Sinon, pensez-vous que ce script pourrait fonctionner avec soit 16Mo,
soit 32Mo configurés dans le fichiers /etc/php.ini de configuration de PHP ?

Le serveur est un serveur dédié, pas de problème pour changer la
configuration.

Le script est relativement peu gourmand en ressources MySQL: Une
grande boucle de lecture, plus un chouïa de lecture par ci par là durant
l'exécution, plus des insert ponctuels non groupés. La boucle principale
de lecture, est la seule dont la mémoire n'est libérée, qu'à la fin de
l'exécution du script, la lecture SQL comme vous le savez, est
bufferisée, et les données lues transitent entre la table SQL lue et la
mémoire, de manière cool en terme d'occupation mémoire.

Ce script n'est pas destiné à un usage intensif, il sert uniquement à
la mise à jour des statistiques sur les pronostics de mon site
partenaire, ces mises à jour auront lieu une fois par jour, et à priori,
ne concerneront que les pronostics de la veille.

Merci beaucoup de vos réponses.

Jean-Francois Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com

10 réponses

1 2 3
Avatar
Bruno Desthuilliers
Bonjour

Je suis en train de terminer un script PHP, assez gros.

Voici les dimensions approximatives:

longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par
script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire
allouée ?


Je ne pense pas que la taille (en LOC) du script ait une influence
majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la
mémoire avec un script de trois/quatres lignes.

Avatar
Thierry B.
--{ Jean-Francois Ortolo a plopé ceci: }--

Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

J'y crois pas, c'est impossible. C'est un troll patatoïde.


--
Divorce d'état: revenus doublés. C'est la France qui avance.

Avatar
beepee
Bruno Desthuilliers a exposé le 01/02/2008 :
Bonjour

Je suis en train de terminer un script PHP, assez gros.

Voici les dimensions approximatives:

longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par
script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire
allouée ?


Je ne pense pas que la taille (en LOC) du script ait une influence majeure
sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec
un script de trois/quatres lignes.


aoué ? fait péter les 4 lignes s'il te plait.

merci d'avance


Avatar
Jean-Francois Ortolo
Bonjour

Je suis en train de terminer un script PHP, assez gros.

Voici les dimensions approximatives:

longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo
par script ), suffira pour qu'il n'y ait pas d'erreur par manque de
mémoire allouée ?


Je ne pense pas que la taille (en LOC) du script ait une influence
majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la
mémoire avec un script de trois/quatres lignes.



Bonjour Monsieur

Il est vrai que mon script a un certain nombre de variables indicées,
mais il me semble qu'au total, l'occupation mémoire spécifique de ces
variables, devrait au total, rester largement en dessous de 1 Mo.

Le volume occupé par toutes les variables, est relativement constant
au fur et à mesure de l'exécution du script, mais il y a bien libération
de la mémoire avec des unset, au fur et à mesure, ce qui éventuellement
peut poser des problèmes d'allocation mémoire.

Je m'inquitéais surtout à cause de la taille en octets de mon script,
qui fera environ 562500 octets de long. ( un peu plus d'un
demi-méga-octets quand même ).

Je suppose que dans un environnement serveur Linux ( actuellement
RedHat 7.2, bientôt Linux Fedora Core 4 ), la mémoire RAM n'est pas
segmentée, c'est la moindre des choses...

Merci beaucoup de votre réponse.

Bien à vous.

Amicalement.

Jean-Francois Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com


Avatar
Olivier Miakinen

Je ne pense pas que la taille (en LOC) du script ait une influence majeure
sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec
un script de trois/quatres lignes.


aoué ? fait péter les 4 lignes s'il te plait.


Je peux jouer ? J'essaierais bien un truc comme ça :

<?php
$str = "blabla";
while(1) { $str = $str.$str; $tableau[$str] = $str; }
?>


Avatar
Jean-Francois Ortolo
--{ Jean-Francois Ortolo a plopé ceci: }--

Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes

J'y crois pas, c'est impossible. C'est un troll patatoïde.




Bonjour Monsieur

Je vous garantis, que je suis bien en train de mettre au point (
terminer de programmer ) ce script, qui a actuellement, pour être
précis, les dimensions suivantes:

longueur : 562423 caractères ascii ( ou octets si vous préférez ),
nbre lignes : 21781 lignes

Je n'ai pas encore testé ce script, pour la simple raison qu'il n'est
pas entièrement terminé. Cependant, j'ai testé et mis au point ce script
à un moment où il était réduit à une fraction de ses fonctionnalités, à
savoir le nettoyage en amont des données qu'il traite. Il a ensuite été
complété par le calcul des variables statistiques. Je maîtrise bien la
structure du script, et il compile par faitement bien, ce qui je le
reconnais, ne veut pas dire qu'il n'y a pas quelques erreurs
d'orthographe de variables...

Ces données traitées, sont lues dans une table SQL dans la boucle la
plus externe, c'est le traitement SQL qui nécessite le plus de mémoire,
puisque le buffer n'est libéré qu'à la fin de l'exécution du script.

Les dimensions actuelles du script, sont motivées par le fait que ces
données font l'objet d'un traitement sophistiqué de calcul, pour
calculer les données statistiques temporaires, puis finales.

Ces données statistiques temporaires puis finales, sont contenues
dans des variables indicées à deux et à trois indices, dont j'ai déjà
dit, que leur volume global est certainement inférieur à 1Mo.

Cependant, le fait que certaines variables temporaires voient leur
mémoire libérée en cours de route ( par des unset ), fait que la mémoire
effectivement allouée, peut être supérieure à l'addition des mémoires de
toutes les variables.

Je reconnais qu'un script aussi important est peu courant en PHP, mais
il n'y a pas d'autre solution pour calculer des statistiques qui
doivent pouvoir être mises à jour quotidiennement, sans que celà n'ait
d'impact négatif sur la justesse des statistiques.

D'autre part, il sera possible, avec cette approche, d'afficher des
stats en choisissant soit des catégories de stats ( nom du pronostiqueur
par exemple puisque ce sont des stats de pronostics de courses de
chevaux ), soit des périodes prise en compte des stats ( exemple les 6
premier mois de 2006, ou toute l'année 2007, etc... ).

Celà dit, si une telle dimension de script est si inhabituelle,
est-il possible à priori, de répondre à la question que je me pose, qui
conditionne la faisabilité de ce projet ?

Merci beaucoup de votre réponse.

Jean-Francois Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com


Avatar
doug713705
Le vendredi 1 février 2008 19:15, Jean-Francois Ortolo s'est exprimé de la
sorte sur fr.comp.lang.php :

Je m'inquitéais surtout à cause de la taille en octets de mon script,
qui fera environ 562500 octets de long. ( un peu plus d'un
demi-méga-octets quand même ).


C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas
passer.

Pour cela, ajuster la variable "max_execution_time" devrait sauver
l'affaire.

--
@+
Doug - Linux user #307925 - Gentoo rocks ;-)
[ Plus ou moins avec une chance de peut-être ]
- Pour me contacter, enlever nospam (2X) -

Avatar
Jean-Francois Ortolo

C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas
passer.

Pour cela, ajuster la variable "max_execution_time" devrait sauver
l'affaire.



Bonjour Monsieur

Je pense qu'il n'y aura pas de problèmes de ce côté-là, parce que je
peux, pour traiter plus d'une journée de courses, spécifier une date
début et une date fin, donc réduire le traitement de chaque appel au
script, à une seule journée de courses.

Actuellement, le temps limite d'exécution est de 30 secondes.

Il y a un nombre limité de pronostiqueurs ( moins de 10 ), évidemment
un nombre limité de courses et de résultats par jour, et ce qui prendra
du temps à l'exécution, sera au pif, 1/3 ou 1/4 pour le nettoyage des
données en amont ( qui sont effectivement un peu parasitées ), et 2/3 ou
3/4 pour la mise à jour des statistiques, et leur intégration à la base
de données.

A un moment où il n'y avait comme fonctionnalité, que le nettoyage
des données, j'avais un temps d'exécution limite correspondant à un peu
plus d'un mois de courses ( donc 30 jours ). Je pense donc que
proportionnellement parlant, il ne devrait pas y avoir de difficultés
pour, au pire, mettre à jour les stats une journée à la fois.

L'appel à ce script PHP se fera à partir d'un script Shell qui
lancera répétitivement le programme curl avec les paramètres qui vont
bien, les dates début et fin seront calculées dans le script Shell de
manière adéquate, et il y aura même une procédure automatique de reprise
sur incident, au cas où le script n'arrive pas jusqu'au bout de son
exécution ( annulation et retour à l'état antérieur des données en base
de données. )

Merci beaucoup de votre réponse, qui m'apporte effectivement
également la réponse au problème du temps limite d'exécution.

Bien à vous.

Amicalement.

Jean-Francois Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com

Avatar
doug713705
Le samedi 2 février 2008 13:14, Jean-Francois Ortolo s'est exprimé de la
sorte sur fr.comp.lang.php :

L'appel à ce script PHP se fera à partir d'un script Shell qui
lancera répétitivement le programme curl avec les paramètres qui vont
bien


Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ?
Si le script ne fait que des insertions/mises à jour/suppressions de données
et aucun d'affichage, une tâche cron et hop ca roulaize, non ?


--
@+
Doug - Linux user #307925 - Gentoo rocks ;-)
[ Plus ou moins avec une chance de peut-être ]
- Pour me contacter, enlever nospam (2X) -

Avatar
Jean-Francois Ortolo

Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ?
Si le script ne fait que des insertions/mises à jour/suppressions de données
et aucun d'affichage, une tâche cron et hop ca roulaize, non ?




A vrai dire...

J'ai besoin que le script me rende quelque chose disant qu'il est
allé jusqu'au bout sans problème.

Je fais çà en lui faisant afficher la chaîne: "OK" en fin de script.

Je me suis arrangé pour que le script Shell prenne automatiquement en
compte l'absence ou la présence de cette chaîne rendue par le script,
pour faire un traitement de reprise sur incident ( annulation des
opérations sur bdd ) si cette chaîne n'est pas envoyée par le script.

Sinon, je sais pas comment le processus Shell de l'interpréteur PHP
en mode CLI, pourrait rendre un numéro interprétable par le script
Shell, en sortie du script PHP.

Je sais que quand on lance une commande dans un script Shell, la
variable $? rend le code de retour de la commande. Mais je ne sais pas
comment agir sur le code de retour du script PHP, quand il est
interprété ( ou compilé just in time ) par l'interpréteur PHP en mode CLI.

Merci beaucoup de ta réponse.

Amicalement.

Jean-Francois Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com

1 2 3