J'ai régulièrement sur mon site les deux erreurs suivantes :
Ces 2 erreurs surviennent un peu n'importe où sur le site, et ne renvoient jamais les mêmes pages et lignes ou requêtes.
J'ai essayé d'augmenter la variable memory_limit à 256M au lieu de 128M, mais ca me semble beaucoup, et ça ne résout pas le problème.

Es-ce que ces erreurs peuvent venir du fait qu'il n'y est pas physiquement assez de RAM sur le serveur ? J'ai la possibilité d'augmenter la RAM sur le serveur pour quelques euros par mois.

Merci de votre aide !

Un détail que je chercherais, ce serait quelle requête est exécutée avant celle indiquée par le message d'erreur.
Par exemple, un SELECT COUNT(*) ne retourne qu'un unique nombre, il est totalement improbable que ce soit de nature à boucher la mémoire, Mais si juste avant il y a un SELECT * sur une table comportant 250 colonnes et un million de lignes, ça pourrait par contre s'expliquer tout seul.

À moins qu'il n'y ait de la requête en boucle quelque part, ça serait tout aussi néfaste. Active les logs MySQL si ce n'est déjà fait, incluant les requêtes normales et les requêtes lentes. Tu y trouveras certainement des indications utiles.

A priori non, la table qui a le plus d'enregistrements n'en a que 12 000, et celle qui a le plus de colonnes n'en a que 40.

Mais c'est finalement assez rare que ce soit une erreur mysql, le plus souvent, c'est l'erreur php "Fatal error: Out of memory (allocated 2883584) (tried to allocate 19456 bytes) in /srv/d_rueverte/www/www.rueverte.fr/htdocs/lemag/wp-includes/formatting.php on line 48" qui se produit. Enfin, c'est rarement 2 fois le même fichier qui est indiqué.

Pour le moment j'ai ajouté de la RAM au serveur, mais j'aurais bien aimé savoir si ajouter de la RAM physiquement n'était pas inutile ?

Ce ne sera réellement inutile que si tu n'adaptes pas l'allocation de mémoire dans le php.ini. Mais si tu le fais également, il reste à trouver ce qui déclenche ça. Peut-être une extension un peu exotique activée et qui génère un conflit avec une autre, sinon je ne vois pas trop.

Cela dit, ce n'est pas le wordpress qui apparait dans l'url qui pose problème, enfin il n'est pas plus suspect que le reste, l'erreur se produit un peu partout. Mon site est une boutique sous oscommerce, avec un wordpress intégré.
Mais j'ai codé de nombreuses choses moi-même, j'ai pas mal transformé jusqu'au coeur d'oscommerce, et j'ai appris le php sur le tas, donc si ca doit venir d'un bout de code un peu trop gourmand, ca ne serait pas non plus dingue.

Lorsqu'on a ce genre d'erreur, on peut suspecter tout ce qui doit être exécuté pour que la page se charge ? Je veux dire, c'est l'ensemble de l’exécution de la page qui est trop gourmand en mémoire, donc ça peut venir de plusieurs lignes de codes mal foutues qui s'accumulent et entraîne le dépassement de la limite en mémoire ?

Mouais, pour vérifier ça, il faudrait un outil de profiling pour tester un pe les pages qui posent problème et voir un peu les appels en isolant les plus gourmands en temps. Ça existe peut-être en outil indépendant, je ne sais pas trop, moi j'utilise ça avec le Zend Studio dans lequel c'est intégré, c'est assez pratique occasionnellement. D'autres que moi auront peut-être une idée à suggérer pour profiler les pages si tu n'as pas le Zend Studio ? Peut-être du coté d'Éclipse PDT ?

Peut-être du coté d'Éclipse PDT ?

oui, avec xdebug + webgrind

Bon, et beh je croise les doigts pour ne pas avoir à installer tout ça et que l'erreur ne revienne pas maintenant que j'ai augmenté la ram
Merci !

Bon, et beh je croise les doigts pour ne pas avoir à installer tout ça

J'ignore quel genre d'éditeur de code tu utilises, mais quelque chose comme Eclipse PDT ou Zend Studio n'a rien d'effrayant et c'est d'abord et avant tout un outil pour se simplifier la vie. Ça signifie donc également un outil comprenant des options utilisables pour déboguer du code, et là, c'est carrément indispensable. La bonne vieille méthode à coup de var_dump() un peu partout fonctionnera toujours, mais ça reste quand même très laborieux pour ne pas dire épuisant.

Ce ne serait donc pas une malchance de devoir installer tout ça, surtout que ce « tout ça » se résume à un IDE et à un plugin dans le cas « Eclipse PDT + xdebug », pas vraiment de quoi en faire un fromage, et encore plus simple pour Zend Studio puisque tout est intégré dedans et que l'installation comporte même l'installation d'une barre d'outils dédiée dans Firefox et/ou dans IE pour lancer du débogage ou le profilage d'une page.

Je code sous dreamweaver. J'utilise pas grand chose de ce que ca propose, je l'utilise comme un editeur de code qui me permet d'accéder facilement à tout les fichiers. Sans doute pour ce que j'en fait, il y aurait des solutions bien moins lourdes, mais ça fonctionne plutôt bien. Peut-être qu'il y a des fonctions de débuggage, surement même, mais je n'ai pas trop regardé. A l'occasion, il faudra que je me penche là dessus.
Mais je reconnais que pour un développeur php, coder comme je le fait, se serait du suicide . Les bugs, je les découvre directement sur la page du site, c'est parfois laborieux oui, ne serait-ce que pour un point virgule oublié chiant à trouver. Heureusement, je ne développe rien de très lourd.