0

Hello!

I have a web-app running on a paid VPS. No problem there. I'm moving this app to my own dedicated server.

Current Cloud Server -CS-: Centos 6 x86_64; 2 Gb Ram; 2 vCPU

Virtual on Dedicated Server: Centos 7 x86_64; 2 Gb Ram; 2 vCPU

I deployed the PC with the same specs because "if it works okay with that it should work with the same".

On a API's endpoint the current CS returns the correct json. The new Server returns:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4294967296 bytes) in /var/www/api/Components/Database.php on line 439

line 439 is:

call_user_func_array(array($stmt, 'bind_result'), $parameters);

The search results I found here and there were not helpful. Some said upgrade PHP version and 90% of them is set a larger memory limit. ** I did**. I set it to 256M, 512M, 2GB (beyond this there is no ram available), 4GB and 5GB. ** Nada**

This query works ok on the other -and production- server.

New server:

Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9        

PHP/5.4.16 mod_wsgi/3.4 Python/2.7.5 
X-Powered-By: PHP/5.4.16

CS:

 Server: Apache 
 X-Powered-By: PHP/5.5.22

I look at the LENGTH of the base64 being queried. They're 2 images data sent. This size is returned by mysql:

select LENGTH(image_base64) from pmv where pmv.model = 1;

That is the query. It returns 2 row. Image_base64 is LONGTEXT. There are some others columns but it won't add to the issue.

LENGTH(image_base64)
162678
131402

It is clearly not close to 4Gb

I can't access php/apache conf on the CS. The only thing I didn't try yet is upgrading PHP from 5.4 to 5.5. Could be it? I'll try to get access to the server on weekend to try out any other ideas.

Edit #1

I update the PHP Version to 5.6.9.

Same error:

<b>Fatal error</b>:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 4294967296 bytes) in <b>/var/www/api/Components/Database.php</b> on line <b>439</b><br />

Edit #2

Changing the column type from longtext to mediumtext seems to work as in this question

But why on earth I need to change the column type on this server? As far I can test now, no matter how much info is stored on that column. It will give the error as long as it's a longtext col.

Thanks!

Community
  • 1
  • 1
Esselans
  • 1,484
  • 2
  • 24
  • 43
  • From the look of the failing filename, and the bind_result, it certainly appears to be doing a database query. I would suggest that the size of the data being returned is the base cause of the issues - making this a SQL issue, not PHP. Do you need to return so much data at once? – Alister Bulman Jun 12 '15 at 22:23
  • @AlisterBulman mysql returns a base64 of a image to be recreated on client. It real size of the image is ~300K. But PHP is complaining about allocating 4gb – Esselans Jun 12 '15 at 22:25
  • Just one? What is the SQL? – Alister Bulman Jun 12 '15 at 22:26
  • @AlisterBulman see edit. Thanks! – Esselans Jun 12 '15 at 22:30
  • It sounds like a software bug handling blob column type. I would upgrade the php to see if it goes away. – Tim3880 Jun 12 '15 at 22:30
  • Are you in a class' method ? Or in the global space ? – Ivan Gabriele Jun 12 '15 at 22:31
  • @IvanGabriele it's a method of http://saskphp.com/ (I'm using that for the API. Works OK on local, staging, production. But with this dedidacted server is my 2nd attempt to make it work. – Esselans Jun 12 '15 at 22:34
  • Ok :) And could my other question below help you ? – Ivan Gabriele Jun 12 '15 at 22:37

2 Answers2

2

4294967296 bytes sounds like really a lot. You surely have a memory leak somewhere.

You should read that :

People, changing the memory_limit by ini_set('memory_limit', '-1'); is NOT a solution at all.

Please don't do that. Obviously php has a memory leak somewhere and you are telling the server to just use all the memory that it wants. The problem has not been fixed at all

UPDATE

As explained in this bug report :

This is a known limitation of ext/mysqli when using libmysql (always in 5.2 and previous) and when libmysql is enabled with 5.3 . The reason is that the server sends not too specific metadata about the column. This longtext has a max length of 4G and ext/mysqli tries to bind with the max length, to be sure no data loss occurs (data doesn't fit in the bind buffer on C level).

So to fix that, you have 4 solutions :

  • You can use a text or mediumtext instead of a longblob or longtext to use less memory
  • You can use PDO connector instead of mysqli but I don't know if it's a easy thing to implement in SaskPhp
  • You can use mysqli_stmt_store_result() to store you data locally, which will also increase your memory usage but really less since it's shared with the buffer size.
  • You can upgrade your PHP with a version superior to 5.3.

Personally, I would go for the fourth one since having an recent version generally bring you many more advantages if it doesn't oblige you to refactor significant parts of your code.

Community
  • 1
  • 1
Ivan Gabriele
  • 5,018
  • 3
  • 31
  • 52
  • put in perspective, it's over 4GB. and yes you really should fix it at that amount – Dendromaniac Jun 12 '15 at 22:22
  • It does. But the same call to the api on both servers at the same time give different results. It's the same code and database on both ends. – Esselans Jun 12 '15 at 22:22
  • 1
    Also is this bug linked to your table types : http://stackoverflow.com/questions/18121619/allowed-memory-size-of-134217728-bytes-exhausted-tried-to-allocate-4294967296-b ? – Ivan Gabriele Jun 12 '15 at 22:33
  • I'll try that. However it does not explain why it already works on other setup. – Esselans Jun 12 '15 at 22:37
  • @IvanGabriele 4.4.17 of ... ? I'll try it though – Esselans Jun 12 '15 at 22:40
  • 1
    No sorry I deleted it because that was false : https://bugs.php.net/bug.php?id=51386. It has not been patched at least until PHP 5.2.13 but maybe later (via mysqli extension). – Ivan Gabriele Jun 12 '15 at 22:42
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – ivan.sim Jun 13 '15 at 04:22
  • @isim : I corrected my answer, giving more details that will answer the **Edit #2** :) – Ivan Gabriele Jun 13 '15 at 09:15
  • I installed php 5.6.9. (current server has 5.5.2). The issue will longtext stand still with this version. The error is on another extension I think. – Esselans Jun 13 '15 at 12:51
  • :/ Did you try to use PDO ? – Ivan Gabriele Jun 13 '15 at 13:54
0

As presented in this SO answer, you could try the following:

ini_set('memory_limit', -1);

You should however attempt to find where the memory is going, it is always best fixing than forgetting!

This is even more relevant in this case, seeing that you have a usage of over 4GB, that is one hell of a memory leak.

Community
  • 1
  • 1
Dendromaniac
  • 368
  • 1
  • 14
  • 1
    Tried a sec ago. It says the same error. And as the machine only has 2gb ram it can allocate. But the query size is not even close to 4GB – Esselans Jun 12 '15 at 22:23
  • @Engerlost Take a look please: http://i.gyazo.com/6b932c2c1f9ac3012dce5511aff5ade4.png – Dendromaniac Jun 12 '15 at 22:26
  • 1
    There's no leak on the production server and the data being sent are 2 images. IMO its a bug and the error message makes no sense. – Esselans Jun 12 '15 at 22:32
  • Very, very strange. I'll take a look into it when I can, I'll get back to you ASAP. – Dendromaniac Jun 12 '15 at 22:38
  • thanks for looking it up. I'll post more info as I get it. But for now I can't access the server until tomorrow – Esselans Jun 12 '15 at 22:44
  • Look at edit #2. It's working now. I'm trying to know what kind of impact this change might have – Esselans Jun 13 '15 at 01:26