Bonsoir,
J'ai l'erreur suivante sur une CVS de fin octobre.
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 1390425 bytes) in /space_3/creagh/ecrire/inc_version.php3 on line
907
Une piste ?
Bonsoir,
J'ai l'erreur suivante sur une CVS de fin octobre.
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 1390425 bytes) in /space_3/creagh/ecrire/inc_version.php3 on line
907Une piste ?
Spip a bouffé toute la RAM. Quelle etait l'url au momnent du meurtre?
M.
JMB wrote:
Bonsoir,
J'ai l'erreur suivante sur une CVS de fin octobre.
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 1390425 bytes) in /space_3/creagh/ecrire/inc_version.php3 on line
907Une piste ?
modifie dans ton php.ini la valeur suivante 
:
memory_limit = 16M
Erwan
modifie dans ton php.ini la valeur suivante
> memory_limit = 16M
Bonjour,
je suis hébergé chez lautre.net et je n'ai pas l'impression qu'ils vont
accepter ce changement ! Ils vont plutôt me demander d'être moins gourmand !
JMB
Erwan LE BESCOND a écrit :
JMB wrote:
Bonsoir,
J'ai l'erreur suivante sur une CVS de fin octobre.
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 1390425 bytes) in /space_3/creagh/ecrire/inc_version.php3 on line
907Une piste ?
modifie dans ton php.ini la valeur suivante
memory_limit = 16M
Erwan
Voici une méthode une méthode gruiikkk pour pallier un soucis de programation. Bonjour monsieur Free, pourriez vous augmenter la mémoire du serveur pour mon Spip?
Dans la charte de Spip, il est dit : Spip tournera sur des serveurs mutualisés avec des spécificités éxotiques et des restrictions fantaisistes.
M.
Mathieu Lecarme wrote:
Erwan LE BESCOND a écrit :
JMB wrote:
Bonsoir,
J'ai l'erreur suivante sur une CVS de fin octobre.
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 1390425 bytes) in /space_3/creagh/ecrire/inc_version.php3 on line
907Une piste ?
modifie dans ton php.ini la valeur suivante
memory_limit = 16M
Erwan
Voici une méthode une méthode gruiikkk pour pallier un soucis de programation. Bonjour monsieur Free, pourriez vous augmenter la mémoire du serveur pour mon Spip?
Dans la charte de Spip, il est dit : Spip tournera sur des serveurs mutualisés avec des spécificités éxotiques et des restrictions fantaisistes.
oui je le sais bien mais c'était juste pour le plaisir de vous écrire parce que ça me rappelle certains pb rencontrés sur un projet voisin ...
Erwan
Bonsoir,
J'ai l'erreur suivante sur une CVS de fin octobre.
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 1390425 bytes) in /space_3/creagh/ecrire/inc_version.php3 on line
907Une piste ?
modifie dans ton php.ini la valeur suivante
memory_limit = 16M
Erwan
Voici une méthode une méthode gruiikkk pour pallier un soucis de programation. Bonjour monsieur Free, pourriez vous augmenter la mémoire du serveur pour mon Spip?
Dans la charte de Spip, il est dit : Spip tournera sur des serveurs mutualisés avec des spécificités éxotiques et des restrictions fantaisistes.oui je le sais bien mais c'était juste pour le plaisir de vous écrire parce que ça me rappelle certains pb rencontrés sur un projet voisin ...
Erwan
Quel projet voisin? 
Sinon, pour voir (un petit peu) ce que fait PHP pour pourrir la RAM comme ça, il existe un excellent jouet : apd
qui permet une analyse postmortem d'une page. Sinon, il y a les classiques var_dump($GLOBALS) qui peuvent donner un aperçu des dégats. Il est possible aussi d'attraper les requetes SQL.
Il faut ensuite se fader la partie la plus interessante du travail : trouver le fichier PHP ou se trouve le code pourri, corriger, et integrer ça au "core".
M.
oui je le sais bien mais c'était juste pour le plaisir de vous écrire
parce que ça me rappelle certains pb rencontrés sur un projet voisin ...
troll alerte !!!!
1- Je constate que les termes commencent à changer : "projet voisin", comme
c'est mignon, et dire qu'il y a quelques mois, on avait droit à des beaux
discours sur le "merge" et autres c.... pour dire que non, non, pas du tout,
ca n'est pas un fork.
2- Pour ceux qui suivent un peu, la version CVS est en beta.
la version utilisée date un peu et des modifs ont été faites sur le cron qui
n'arrivait pas jusqu'à la syndication, c'est peut etre lié, d'autant qu'il
reste des choses à voir de ce coté la, si j'ai bien suivi.
Une remarque constructive aurait pu etre :
- Mettre à jour ta CVS et voir si c'est reproductible
- Evaluer les parametres responsables du probleme (grosse base, beaucoup de
syndication, beaucoup d'auteur, envoi d'email massif ...)
3- Le "projet voisin", meme si dans sa dernière version beta semble 10 fois
plus rapide (à en croire les developpeurs, vu le grand nombre
d'utilisateurs), reste 5 ou 6 fois plus lent que l'original et necessite,
outre ses 16Mo, quelques modules PEAR ...
4- Si, comme je le pense, le "projet voisin" compte sur la sortie de la 1.8
pour resoudre quelques uns de ses problemes de perf., il ferait mieux de
rester aussi discret qu'à son lancement, et, comme son lancement, faire un
petit copier dans son coin, en se gardant bien de faire remonter la mondre
remarque constructive sur cette liste !
A bon entendeur.
Stephane.
PS : c'est pas parce qu'il n'y a que 2 messages par semaine sur la "liste
voisine" qu'il faut venir poluer celle-ci.
Il serait par contre interessant de transferer ce message sur la "liste
voisine", que les rares utilisateurs du "produit voisin" comprenne comme les
beaux discours sur la volonté de travailler avec Spip sont loin de la
réalité.
Spip a bouffé toute la RAM. Quelle etait l'url au momnent du meurtre?
Salut
je me rends compte que je n'avais pas répondu à ce message. En fait, c'est
le rédacteur du site qui m'a fait passer cela... sans l'URL ! Je la lui ai
demandé mais, travaillant la nuit sur le site, il dort le matin ! C'est ça,
les retraités !
Si j'ai alerté c'est que j'ai eu cela l'autre jour et un recalcul de page a
réglé le problème : je ne m'étais donc pas inquiété. Mais le problème
revenant, je commence à me faire du soucis !
Je n'ai pas donné le site : c'est http://raforum.apinc.org et c'est vrai que
l'indexation (mots-clés) de ce site grossit de jour en jour. Peut-être
est-ce lié ?
Dès que j'ai l'URL, je vous la fais suivre. Et je vais demandé à lautre.net,
notre hébergeur, s'il n'a pas des logs pour voir si c'est occasionnel ou
récurrent.
Par contre, au niveau de la CVS, j'ai arrêté le 29/10 (ou dans ces eaux)
car, après, cela a beaucoup bougé et comme c'est un site en prod, je n'ai
pas voulu prendre trop de risques. J'ai donc dû louper certaines
améliorations.
JMB
Hello,
J'ai personellement eu le même probléme avec la version CVS d'hier (16Noc) matin:
"PHP Warning: POST Content-Length of 32491239 bytes exceeds the limit of 8388608 bytes in Unknown on line 0"
mais comme ca vient des logs du serveur, je ne sais pas du tout quel page est en cause.
Mais je peux affirmer une chose, ca ne vient pas d'une DB trop grosse (je n'ai que 55 articles 
Pierre
JMB wrote:
Dès que j'ai l'URL, je vous la fais suivre. Et je vais demandé à
lautre.net,
notre hébergeur, s'il n'a pas des logs pour voir si c'est occasionnel ou
récurrent.
Comme un benêt, j'ai posté un message à lautre.net au lieu de apinc.org !
car il s'agit bien d'un site apinc !
JMB
2- Pour ceux qui suivent un peu, la version CVS est en beta.
C'est aussi le cas du projet voisin.
3- Le "projet voisin", [snip]reste 5 ou 6 fois plus lent que l'original et
necessite,
Preuves?
outre ses 16Mo,
Preuves?
quelques modules PEAR ...
Et? C'est comme si on rapprochait a JBoss d'avoir besoin de Java EE.
4- Si, comme je le pense, le "projet voisin" compte sur la sortie de la 1.8
pour resoudre quelques uns de ses problemes de perf.,
Preuves?
C'est facile de cracher sur les autres.
il ferait mieux de
rester aussi discret qu'à son lancement, et, comme son lancement, faire un
petit copier dans son coin, en se gardant bien de faire remonter la mondre
remarque constructive sur cette liste !
? J'ai du mal a comprendre ce que tu veux dire.
PS : c'est pas parce qu'il n'y a que 2 messages par semaine sur la "liste
voisine"
Preuves?
qu'il faut venir poluer celle-ci.
Question generale: est-ce que c'est un avis generale ou juste une opinion de
Mister Laurent?
Il serait par contre interessant de transferer ce message sur la "liste
voisine", que les rares utilisateurs du "produit voisin" comprenne comme
les beaux discours sur la volonté de travailler avec Spip sont loin de la
réalité.
Tu es libre de faire cela. De toute facon, si je comprend bien, tu es aussi
abonne de agora-generale et agora-devel.
Je crois qu'en plus, la-bas, ce genre de discussion vont provoquer un long et
magnifique flamewar, comme l'habitude le montre... (et malheuresement)
Cordialement
Maciek
3- Le "projet voisin", [snip]reste 5 ou 6 fois plus lent que l'original
et
necessite,
Preuves?
temps annoncés sur la liste voisine pour afficher une page dans le back.
outre ses 16Mo,
Preuves?
voir doc Agora
quelques modules PEAR ...
Et? C'est comme si on rapprochait a JBoss d'avoir besoin de Java EE.
Et il est rarement possible de les installer sur un serveur mutualisé.
Et ce n'est pas à la porté de tout le monde.
4- Si, comme je le pense, le "projet voisin" compte sur la sortie de la
1.8
pour resoudre quelques uns de ses problemes de perf.,
Preuves?
Non, constat.
Et quelques mails sur la "liste voisine" disant que vous "suiviez ca de
pret".
C'est facile de cracher sur les autres.
Presque aussi facile que de faire un copier coller ...
il ferait mieux de
rester aussi discret qu'à son lancement, et, comme son lancement, faire
un
petit copier dans son coin, en se gardant bien de faire remonter la
mondre
remarque constructive sur cette liste !
? J'ai du mal a comprendre ce que tu veux dire.
Je constate juste que, pour des gens qui "suivent ca de pret", on ne vous
voit pas souvent faire remonter un bug, qu'on attend toujours de voir
comment la "défi du merge" va etre relevé ...
PS : c'est pas parce qu'il n'y a que 2 messages par semaine sur la "liste
voisine"Preuves?
Je parlais de la liste "generale", pas du forum de CE, heu, pardon, de la
liste dev.
:o)
qu'il faut venir poluer celle-ci.
Question generale: est-ce que c'est un avis generale ou juste une opinion
de
Mister Laurent?
Simplement mon avis, comme tout post sur une liste, sauf si on se prend pour
dieu le pere
Pour commencer, je suis arrivé à Spip aprés le schisme, mais j'ai vu qu'Agora c'est bien fait pourrir, et que certains choix sont discutables (pearDB par exemple).
Mais si tu n'aimes pas Agora, la meilleur méthode, c'est de les ignorer, je ne penses pas que leur chier dessus (quelques soit l'étendu de leur crime) soit trés constructif.
Si Agora a envie de merger, c'est une TRES bonne idée, mais si à la moindre remarques sur la liste, quelqu'un les pourris, ils vont pas être trés motivé.
Sinon, PEAR n'est pas une abbération en tant que tel, il faut juste avoir accés à un dossier que php.ini appelle comme un dossier de bibliothèques, certains hebergements mutualisés le font. Par contre PEARdb est lent et bouffe plein de ressource, c'est sur.
Ensuite les patchs sont aussi un sujet polémique sur la liste, si il n'est pas vitale, il est souvent oublié.
Pour les améliorations techniques ou autres discussion constructive, on reste aussi dans le flou.
Regarde le dernier poste d'Antoine sur le core.
La liste Spip fait un peu penser au dessin de presse sur l'affaire Dreyfus "ils en ont parlé".
On va dire que c'est culturel.
M.
Stephane LAURENT a écrit :
3- Le "projet voisin", [snip]reste 5 ou 6 fois plus lent que l'original
et
necessite,
Preuves?
temps annoncés sur la liste voisine pour afficher une page dans le back.
outre ses 16Mo,
Preuves?
voir doc Agora
quelques modules PEAR ...
Et? C'est comme si on rapprochait a JBoss d'avoir besoin de Java EE.
Et il est rarement possible de les installer sur un serveur mutualisé.
Et ce n'est pas à la porté de tout le monde.4- Si, comme je le pense, le "projet voisin" compte sur la sortie de la
1.8
pour resoudre quelques uns de ses problemes de perf.,
Preuves?
Non, constat.
Et quelques mails sur la "liste voisine" disant que vous "suiviez ca de
pret".C'est facile de cracher sur les autres.
Presque aussi facile que de faire un copier coller ...
il ferait mieux de
rester aussi discret qu'à son lancement, et, comme son lancement, faire
un
petit copier dans son coin, en se gardant bien de faire remonter la
mondre
remarque constructive sur cette liste !
? J'ai du mal a comprendre ce que tu veux dire.
Je constate juste que, pour des gens qui "suivent ca de pret", on ne vous
voit pas souvent faire remonter un bug, qu'on attend toujours de voir
comment la "défi du merge" va etre relevé ...PS : c'est pas parce qu'il n'y a que 2 messages par semaine sur la "liste
voisine"
Preuves?
Je parlais de la liste "generale", pas du forum de CE, heu, pardon, de la
liste dev.
:o)qu'il faut venir poluer celle-ci.
Question generale: est-ce que c'est un avis generale ou juste une opinion
de
Mister Laurent?
Simplement mon avis, comme tout post sur une liste, sauf si on se prend pour
dieu le pere
un nouveau troll?
M.
Je suis d'accord. Les gars de PEAR le savent, c'est qui est la moitie de
succes, deja.
Il y a d'autres possibilites pour remplacer DB par quelque chose de plus
rapide et quasi-api-compatible (MDB2 semble etre un candidat). Il faut juste
de la workforce... ou du temps.
Mais ca tourne off-topic. Sorry.
./Maciek
Maciek Borowka a écrit :
Par contre
PEARdb est lent et bouffe plein de ressource, c'est sur.
Je suis d'accord. Les gars de PEAR le savent, c'est qui est la moitie de succes, deja.Il y a d'autres possibilites pour remplacer DB par quelque chose de plus rapide et quasi-api-compatible (MDB2 semble etre un candidat). Il faut juste de la workforce... ou du temps.
Mais ca tourne off-topic. Sorry.
./Maciek
Non, il y a eu une fourchette (un thread) il n'ya pas si longtemps si l'abstraction de base de donnée pour pouvoir gérer PostGres et SQLite.
adodb propose aussi une compatibilité Pear.
C'est quand même mieux de discuter entre gens civilisés, et de voir spip-agora reconnaitre que son choix d'abstraction de base de données n'est pas trés performant.
M.
Mais au moins il est stable et teste depuis N annees (projet Horde utilise le
meme). C'est un argument tres important en faveur de PEAR::Db.
En plus, ses perfs ne sont pas si catastrophiques, a vrai dire. Moins bonnes
que adoDB par exemple, mais en total, on peut vivre avec encore longtemps.
./Maciek
Le message d'erreur dit "POST Content-Length"... Cela veut dire que
l'erreur vient d'un envoi de formulaire, certainement quelqu'un qui a
essayé d'uploader un fichier trop gros (32 Mo, je ne vois que ça).
Amicalement
Antoine.
J'avais pas assez detaillé la difference
Pierre
Antoine wrote:
Maciek Borowka wrote:
qu'il faut venir poluer celle-ci.
Question generale: est-ce que c'est un avis generale ou juste une opinion de Mister Laurent?
Mon avis personnel est que les 2 communautés SPIP et AGORA devraient cesser de se regarder en chien de faïence (au mieux) et songer à travailler pour ce qui est un des beaux projets du libre en France : SPIP.
Antoine met à disposition de ce qui le veulent un espace CVS sur le lab pour faire des SPIP+hors-core (avec l'espoir que ce soit dans le core).
Historiquement parlant, AGORA a dû faire des choses dans l'urgence et de fait, a fait des boulettes d'un point de vu communication avec notre communauté SPIP.
Est-ce que raison pour laisser l'État continuer à payer des développements pour AGORA alors qu'Il pourrait le faire pour SPIP.
Il me semble que c'est déjà le cas avec Linagora qui a 2 contribs sous le coude : mots-clefs en hiérarchie et formulaires paramétrables.
Il y a aussi : http://www.spip-contrib.net/spikini/agora2spip pour centraliser les efforts de rapprochement.
Donc, pour revenir à la question, OUI, je veux que les développeurs d'AGORA et le "Bureau des mainteneurs" viennent sur cette liste pour présenter au moins les directions dans lesquelles ils souhaitent aller.
OUI, je veux qu'ils lancent des projets sur le lab.
PS : je viens de travailler pour le Ministère de l'équipement qui a développé de supers squelettes pour SPIP sur une version modifiées de SPIP 1.6. Eux aussi me semblent les bienvenus sur le lab.
À bon entendeur, salut
Jacques