Weathermap and CactiEZ 0.2b

[Goatmilker]

Hmm, yes indeed. I notice there is mention of "Limit is 8M" at the "memory_get_usage" line although I changed the php.ini several times.

Can you tell me if that is the only parameter I had to change? And if so, what is the process to activate this change if it is not updating its parameters automatically...

Thanks!

[Howie]

Hmm, yes indeed. I notice there is mention of "Limit is 8M" at the "memory_get_usage" line although I changed the php.ini several times.

Can you tell me if that is the only parameter I had to change? And if so, what is the process to activate this change if it is not updating its parameters automatically...

Thanks!

Try checking the output of php -i (near the top), to make sure you're changing the right php.ini? Also, bear in mind that the editor and the poller process run using different php methods (mod_php vs CLI). In some OS, those have different php.ini, so you can have one working and one broken. Debian/Ubuntu does that. I don't know about CentOS (CactiEZ).

[streaker69]

Hmm, yes indeed. I notice there is mention of "Limit is 8M" at the "memory_get_usage" line although I changed the php.ini several times.

Can you tell me if that is the only parameter I had to change? And if so, what is the process to activate this change if it is not updating its parameters automatically...

Thanks!

Try checking the output of php -i (near the top), to make sure you're changing the right php.ini? Also, bear in mind that the editor and the poller process run using different php methods (mod_php vs CLI). In some OS, those have different php.ini, so you can have one working and one broken. Debian/Ubuntu does that. I don't know about CentOS (CactiEZ).

Unless he did something strange to his system, the only PHP.INI file in the CactiEZ setup is in /etc.

[Goatmilker]

Well No, the only php.ini is the one in the /etc and that's the one I've changed.

I've done that php.ini -i and found the next line:

Code: Select all

<tr><td class="e">memory_limit</td><td class="v">128M</td><td class="v">128M</td></tr>

does looks good to me, although when I debug the outcome shows me:

Code: Select all

...
05/09/2007 02:12:57 PM - WEATHERMAP: Poller[0] About to write image file. If this is the last message in your log, increase memory_limit in php.ini
05/09/2007 02:12:57 PM - WEATHERMAP: Poller[0] memory_get_usage() says 1.3MBytes used. Limit is 8M
05/09/2007 02:12:57 PM - WEATHERMAP: Poller[0] Running Post-Processing Plugins...
...

Regards

[streaker69]

Well No, the only php.ini is the one in the /etc and that's the one I've changed.

I've done that php.ini -i and found the next line:

Code: Select all

<tr><td class="e">memory_limit</td><td class="v">128M</td><td class="v">128M</td></tr>

does looks good to me, although when I debug the outcome shows me:

Code: Select all

...
05/09/2007 02:12:57 PM - WEATHERMAP: Poller[0] About to write image file. If this is the last message in your log, increase memory_limit in php.ini
05/09/2007 02:12:57 PM - WEATHERMAP: Poller[0] memory_get_usage() says 1.3MBytes used. Limit is 8M
05/09/2007 02:12:57 PM - WEATHERMAP: Poller[0] Running Post-Processing Plugins...
...

Regards

From the log you posted, it would seem that memory_limit is NOT your problem. As the line says, if it's the LAST line in your log then increase your memory limit, if something comes past that line, then it isn't your problem.

[Goatmilker]

Well, frankly I don't know... I looks like a contradiction to me.

But I find my problem easy to replicate: open the editor.php, add 8 nodes (don't care about position nor other details, just drop them somewhere) and change the default map size from 800x600 to 1200x800 and ... the map is gone!

It gives a feeling that the problem is caused by a lack of memory, but I don't know the program/Linux enough to troubleshoot in the code.

ps: the big map/faulty map is not generated now. will give it an other try.

[Howie]

As the line says, if it's the LAST line in your log then increase your memory limit, if something comes past that line, then it isn't your problem.

Well, actually, in DEBUG mode, I don't know if that's still true. The two lines beyond that are both DEBUG-only things, and both are before it tries to create the blank image for the new map.

A 1024x768 image is roughly 1024x768x4(1 byte per channel) bytes, so that's 3MB or so. When the background image is loaded, that's the same again, so if it thinks you have 8M for whatever reason, that's pretty close if you have a bg image...

[Goatmilker]

So I selected the maps I couldn't see any more in the editor... and finally showed up after 3 - 4 minutes.

Still 2 remarks which troubles me as nobody seems to define the cause...
- Conflicting Memory allocation/reservation in php.ini and DEBUG log
- Does that editor uses the same parameters form the php.ini as developing/editing large images without using the editor (to show the draft) is a bit hard to get coordinates right...

Regards

[Howie]

So I selected the maps I couldn't see any more in the editor... and finally showed up after 3 - 4 minutes.

Still 2 remarks which troubles me as nobody seems to define the cause...
- Conflicting Memory allocation/reservation in php.ini and DEBUG log
- Does that editor uses the same parameters form the php.ini as developing/editing large images without using the editor (to show the draft) is a bit hard to get coordinates right...

Regards

I don't follow what you mean about 3-4 minutes. You mean they appeared in the Cacti weathermap tab? or the editor? It sounds like you just waited a poller cycle, and the maps updated in the tab as they should, which is perfectly normal... or am I missing something?

The editor uses a different PHP module to the poller (mod_php vs the CLI php). On some OS, those have different php.ini paths. It's not a choice the editor makes - it's just the way your system might be set up.

I agree about the conflicting memory errors, but again, all it's doing is asking PHP about memory using the recommended function calls. I don't know why that would give incorrect information, but somehow it doesn't surprise me.

[Goatmilker]

I don't follow what you mean about 3-4 minutes. You mean they appeared in the Cacti weathermap tab? or the editor? It sounds like you just waited a poller cycle, and the maps updated in the tab as they should, which is perfectly normal... or am I missing something?

What I meant is when under Console > Mngmt/Weathermaps > I add a the map I can't see with the editor and select 'Rebuild All Maps Right Now'. Normally you'll see a short debug log ending with a line 'Weathermap 0.9 run complete - x maps were run' ... this time the page stops at the second debug line (like it freeze) and selecting the Weathermaps page the thubmbnail isn't created until 3-4 minutes. So it seems its actually created after all but it takes its time. (by large map I mean the 8 nodes on 1200x800 page no bg! its size is eventually 6.3kB)

The editor uses a different PHP module to the poller (mod_php vs the CLI php). On some OS, those have different php.ini paths. It's not a choice the editor makes - it's just the way your system might be set up.

Any idea how to adjust this? by mod_php you mean a file mod_php.pl called that way? Sorry, not the Linux specialist your talking with...
There is however only one php.ini in my case.

[Howie]

What I meant is when under Console > Mngmt/Weathermaps > I add a the map I can't see with the editor and select 'Rebuild All Maps Right Now'. Normally you'll see a short debug log ending with a line 'Weathermap 0.9 run complete - x maps were run' ... this time the page stops at the second debug line (like it freeze) and selecting the Weathermaps page the thubmbnail isn't created until 3-4 minutes. So it seems its actually created after all but it takes its time. (by large map I mean the 8 nodes on 1200x800 page no bg! its size is eventually 6.3kB)

Yes, but it's uncompressed (before the png file is written to a file) size is 4MB+

So the Rebuild Now (which uses mod_php, same as the editor) died, and the poller (running every 5 minutes from the CLI php) created the maps OK.

Any idea how to adjust this? by mod_php you mean a file mod_php.pl called that way? Sorry, not the Linux specialist your talking with...
There is however only one php.ini in my case.

No - when php pages are run from the Apache webserver (as web pages, like Cacti or the editor), they use an apache module called mod_php, which allows apache to understand php, and send back the right results. When the Cacti poller runs from cron (and it includes the weathermap update process), it uses a different php program. Normally these two are compiled and installed at the same time, but it's possible to have them be different, even completely different versions. Some versions of Linux do this deliberately (e.g. Debian), and it's not that hard to do by accident if you start compiling your own PHP. I don't think any of this affects you though, since CactiEZ comes with all this pre-installed, but there's the explanation

One thing you might like to check (to be really sure), is to create a text file in the weathermap directory, call it 'test.php' or something similar, and put the following in it:

Code: Select all

<?php
  phpinfo();
?>

Then go to http://yourcactiserver/plugins/weathermap/test.php in your browser, and see what that says about php.ini and memory_limit. That page will be produced by the mod_php php, which is the one that Rebuild Now and the editor use.

[Goatmilker]

Wow, thanks a lot, Howie! This explains a lot for me!
I did what you asked so let me share that now.

System Linux localhost.localdomain 2.6.9-42.0.10.EL #1 Tue Feb 27 09:24:42 EST 2007 i686
Build Date Apr 16 2007 13:17:30
...
Configuration File (php.ini) Path /etc/php.ini
Scan this dir for additional .ini files /etc/php.d
...
PHP Core
...
memory_limit 8M 8M
...

So indeed memory_limit is 8M damn mod_php!! my quest seems to continue...

[Howie]

Wow, thanks a lot, Howie! This explains a lot for me!
I did what you asked so let me share that now.

System Linux localhost.localdomain 2.6.9-42.0.10.EL #1 Tue Feb 27 09:24:42 EST 2007 i686
Build Date Apr 16 2007 13:17:30
...
Configuration File (php.ini) Path /etc/php.ini
Scan this dir for additional .ini files /etc/php.d
...
PHP Core
...
memory_limit 8M 8M
...

So indeed memory_limit is 8M damn mod_php!! my quest seems to continue...

OK, but that also tells you that any addition ini files in /etc/php.d/ will be read. You might want to check if there are any in there, and if they contain a memory_limit line, which may undo what you have done in the main php.ini it's all so simple

[Goatmilker]

HUREKA! I found it! (ps: I did looked in that php.d folder but nothing usefull there )
I googled around to see how to increase that memory_limit
in PHP Core... so I found something like

<?php
ini_set("memory_limit", "32M");
phpinfo();
?>

which indeed increased the Local Value, not the Master Value... so that wasn't it... finally some folks told that by creating a .htaccess file and restart the httpd service would solve it... which also didn't solved it however I saw the memory allocation from my php.ini file appearing as Master Value.

So to summarize, for all of those who will stumble on the same issue... restart your HTTPD service to apply your changes!! The editor / Right Now is able to display or generate the maps nicely!

service httpd restart

Damn embarrassing! I could have know that reboot solved the issue Well at least I hope someone else will learn from this!

Thanks Howie & streaker69 for the help guys! what a relief ... large(r) maps here I come!