De façon inattendue frapper PHP limite de mémoire avec une seule requête PDO?

J'ai une requête simple qui ressemble à quelque chose comme:

$result = $pdo->query('SELECT * FROM my_table');

foreach($result as $r) {
    //do some stuff
}

Mais lorsque je l'exécute j'obtiens l'erreur suivante:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /path/to/myfile.php sur la ligne 15

"Ligne 15" étant le $pdo->query ligne.

Si j'ai mis die() après la requête, j'obtiens toujours la même erreur.

Je pensais que ce n'était plus censé chercher une ligne à la fois; pourquoi est-il l'aide d'autant de mémoire?

  • Hrm? Comment est-ce pertinent? Je ne travaille qu'avec $r qui est un enregistrement unique. Pourquoi serait-ce la cause de récupérer des données supplémentaires? ...sauf si il y a une fuite de mémoire dans là et les itérations sont ce qui cause le problème...bien, je vais le poster. Pourquoi le downvote?
  • L'obtention de la mémoire réelle limite d'erreur serait également utile (le libellé utilisé, plesae), ce serait en fait vérification de l'utilisation de la mémoire immédiatement avant la requête. Vous avez peut-être déjà à la limite avant de la requête. Aussi, le nombre d'enregistrements retournés par la requête? Vous êtes en train de faire un SELECT * sans LIMIT. Retour d'un million de lignes va utiliser juste un peu de mémoire.
  • Il n'y a rien avant la requête. Juste la connexion PDO. C'est un très petit script.
  • Mec, c'est l'allocation de 32 octets et vous frappez un 128M limite? Vous avez vraiment besoin de vérifier l'utilisation de la mémoire avant de la requête. Aussi, quelle version de PHP est-ce?
  • Voir la question des mises à jour.
  • L'utilisation de la mémoire est 635384 octets avant d'appeler query. Je devine query alloue en morceaux, pour chaque enregistrement. Ne prouve pas beaucoup. C'est PHP 5.3.17.
  • bon, maintenant, le nombre de lignes renvoyées par la requête, composé de combien d'octets?
  • Il y a ~350 K enregistrements dans la base de données. La PMA dit taille moyenne de ligne est de 159 octets.
  • MySQL, droit? Êtes-vous à l'aide de PDO::MYSQL_ATTR_USE_BUFFERED_QUERY? C'est activé par défaut.
  • Bingo! Personnes handicapées, et maintenant, il fonctionne. Merci!!!! (Faire une réponse et je vais accepter)

InformationsquelleAutor mpen | 2012-12-05
  1. 30

    L'utilisation de la mémoire est 635384 octets avant l'appel de la requête. Je devine requête alloue en morceaux, pour chaque enregistrement.

    Ding ding ding!

    Lors de la connexion à MySQL, PHP aime à l'aide de tampon de requêtes. Cela est vrai quelle que soit la méthode que vous utilisez pour vous connecter. Lors de l'utilisation de tampon de requêtes, l'ensemble du jeu de résultats est chargé immédiatement au lieu d'être récupérées lorsque vous demandez. C'est généralement bon pour les performances, car il y a moins d'aller-retours.

    Mais comme tout en PHP, il y a une chasse aux sorcières. Comme indiqué sur la mise en mémoire tampon de page:

    Lors de l'utilisation de libmysql comme la bibliothèque de la limite mémoire de PHP ne comptera pas la mémoire utilisée pour les jeux de résultats, à moins que l'extraction des données dans des variables PHP. Avec mysqlnd, la mémoire utilisée pour le jeu de résultats.

    Vous êtes à l'aide de PHP 5.3, ce qui signifie qu'il ya une bonne chance que vous êtes à l'aide de mysqlnd.

    Vous aurez envie de désactiver le tampon de requêtes ici. C'est fait différemment dans chaque interface PHP pour MySQL:

    • Pour les AOP, vous aurez besoin de définir les PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribut false.
    • Pour mysqli, vous devez passer la MYSQLI_USE_RESULT constante de la requête méthode.
    • Pour mysql, vous devez appeler mysql_unbuffered_query au lieu de mysql_query.

    Plein de détails et d'exemples sur la page.

    Gros tampon de requête gotcha!

    Vous doit fermer correctement le descripteur d'instruction et gratuit le jeu avant la délivrance d'un autre requête:

    • En PDO, ce moyen d'appel closeCursor sur le descripteur d'instruction.
    • En mysqli, cela signifie que l'appel de free_result sur le descripteur d'instruction ou gratuit sur le résultat de la poignée, en fonction de ce que vous travaillez avec.
    • Dans mysql, cela signifie que l'appel de mysql_free_result

    Ne pas le faire entraînera une erreur.

    • Je ne pense pas que vous devez appeler closeCursor si vous utilisez fetchAll ou effectuer une itération sur l'ensemble de l'ensemble de résultats; seulement quand vous avez unfetched lignes à gauche. De toute façon, super réponse! Merci encore.
    • Honnêtement, je n'ai jamais essayé, comme la combinaison sans tampon et fetchAll sons incroyablement stupide.
    • Il n', sauf si il ya une poignée de cas où vous avez besoin de l'ensemble de résultats complet et vous ne voulez pas retourner la mise sous et hors tension.
    • J'ai atterri ici pour la même erreur, cependant mon problème s'est avéré être un non-existant champ nom. L'amenant à frapper à la limite de la mémoire.
    InformationsquelleAutor Charles