Zend php bellek memory_limit

4 Cevap php

Tümü,

Zend Framework tabanlı bir web uygulaması üzerinde çalışıyorum. Biz dev sunucu üzerinde bellek hataları dışında karşılaşmak tutmak:

XXXX bayt İzin bellek boyutu (denedim YYYY bitkin ...

Biz php.ini artan memory_limit tutmak, ancak 1000 yılı megs kadar şimdi. Normal memory_limit değeri nedir? Bellek tükeniyor için php / Zend olağan şüpheliler nelerdir? Biz Propel ORM kullanıyor.

Tüm yardım için teşekkür ederiz!

Update I cannot reproduce this error in my windows environment. If I set memory_limit low (say 16M), I get the same error, but the "tried to allocate" amount is always something reasonable. For example: (tried to allocate 13344 bytes) If I set the memory very low on the (Fedora 9) server (such as 16M), I get the same thing. consistent, reasonable out of memory errors. However, even when the memory limit is set very high on our server (128M, for example), maybe once a week, I will get an crazy huge memory error: (tried to allocate 1846026201 bytes). I don't know if that might shed any more light onto what is going on. We are using propel 1.5. It sounds like the actual release is going to come out later this month, but it doesn't look like anyone else is having this problem with it anyway. I don't know that Propel is the problem. We are using Zend Server with php 5.2 on the Linux box, and 5.3 locally.

Herhangi fazla fikir? Ben Xdebug Linux'unuzda yüklü almak için bir bilet var.

Teşekkürler,

-Rep

4 Cevap

I think this has something to do with deployment from cruise control. I only get the very high (on the order of gigs) memory error when someone is deploying new code (or just after new code has been deployed). This makes a little bit of sense too since the error always points to a line that is a "require_once." Each time I get an error: Fatal error: Out of memory (allocated 4456448) (tried to allocate 3949907977 bytes) in /directory/file.php on line 2

I have replaced the "require_once" line with: class_exists('Ingrain_Security_Auth') || require('Ingrain/Security/Auth.php');

Ben şimdiye kadar 3 dosya bu satırı yerini almış, ve daha fazla bellek sorunları olmadı. Herkes gidiyor olabilir ne içine biraz aydınlatabilir misiniz? Ben dağıtmak için Cruise Control kullanıyorum.

Genellikle PHP 5.2 ve / veya PHP 5.3 ile, konuşma, ben 32M için daha fazla düşünmek eğilimindedir memory_limit "çok fazla" olduğunu:

  • Altyapıları / ORM ve bu gibi şeyler kullanarak, 16M genellikle yeterli değildir
  • Kullanımı 32M, genellikle I (typical websites) üzerinde çalışıyorum web uygulamaları tür için yeterli
  • Daha fazla kullanarak 64M sunucu biz istediğiniz gibi birçok kullanıcı idare mümkün olmayacak demektir.


When, it comes to a script reaching memory_limit, the usual problem is trying to load too much data into memory ; a couple of examples :

  • Böyle file veya file_get_contents, ya da XML ile ilgili işlevler / sınıflar gibi fonksiyonları ile, bellekte büyük bir dosya yüklüyor
  • Verilerin çok büyük bir dizi oluşturma
  • Çok nesneleri oluşturma

Eğer bir ORM kullanarak göz önüne alındığında, nerede bir durumda olabilir:

  • Sen satır bir sürü döndüren bazı SQL sorgusu yapıyor
  • ORM bir dizi bu koyarak, nesnelerin her satırı dönüştürmektedir
  • In which case a solution would be to load less data
    • Örneğin, sayfa numaralarını kullanan
    • veya nesneler yerine diziler gibi verileri yüklemek için çalışıyorum (I don't know if this is possible with Propel -- but it is with Doctrine ; so maybe Propel has some way of doing that too ? )

Tam olarak uygulama anda ne yaptığını bu bellek çalışır. Bunun için neden bir sürü neden olabilir. Ben en çok yaygın bir diziye çok fazla veri tahsis olacağını söyleyebilirim. Uygulama bu doğrultuda bir şey yapıyor.

İkiniz de belki oluyor iki şeyden birine sahip:

  1. Eğer olması gerektiği zaman sona değil, kaçak bir süreç bir yere sahiptir.
  2. Sen böyle büyük dizeleri veya diziler ya da nesneler gibi, etrafında çok sayıda veri atmak ve onlar sadece ne gerek yerine işleme gereksiz kopyalarını yapmak ve onlar ne atarak algoritmalar var.

etiketler