Clobbered my sites again…

Sure, fair enough.

Hi Camu…

Have heard back from my hosting folks… Here is their response…

In regards to the plugin you requested help with, I’ve re-enabled the plugin and found that it was using a large amount of resources. I’ve increased your accounts system memory usage limit from 2GB to 4GB of ram. After doing this, the pages now appear to load correctly and do not display this error anymore;
“PHP Fatal error: Unsupported operand types in /home/purelig2/public_html/purelightalchemy/wp-content/plugins/wp-slimstat/wp-slimstat.php on line 725” It looks like the process was being terminated due to the account reaching the system memory limit, resulting in that error.

So there were no files being altered or deleted…

As I’ve seen in other threads and reviews here, it is now confirmed for me that slimstat does use a whole heck of a lot of resources… Not so slim, it seems…?

I’ll watch and see how it goes… I do like have the info it gives close at hand like that, but all that resource usage, hmmm…

Two questions, please be direct if you will…

You mentioned that there could be some concern about accuracy of the stats… Is that still a possibility, with what you know here now…?

Is all that resource usage really necessary, or are there some ways that it could be “slimmed down,” so to speak…?

Kind regards,

John.

Having a similar problem on any of the sites where Slimstat is upgraded to 3.8.3. Those sites which are not upgraded, no problems. So far there are 3 sites checked and they each have the exact problem as stated above. The problem is usually reported by SUCURI when running a Malware Scan. Have not [yet] seen the problem anywhere else.

Not quite sure how to relate about Memory. Server has 4Gb Memory, and Swap File is allocated as 10Gb. No indication that we ever run out of a combination of SWAP AND MEMORY.

Looking at the MUNIN Stats for today it is showing Max Memory for Apps 1.09G, Swap Cache 680M, Slab Cache 200M, Cache 2.3G, Buffers 369M, UNUSED 516M, Swap 3.42G, Inactive 1.57G, Committed, 9.1G, Active 2.9G, Mapped, 829M

Not sure if any of that helps much, but…….

If running out of memory is a problem, then perhaps some code can be added to detect that situation and avoid the crash and gracefully terminate and perhaps send a message to the administrator for reference.

Regards

John B

I’m seeing this issue as well:

2014/11/23 02:15:02 [error] 16299#0: *357665 FastCGI sent in stderr: "PHP Fatal error:  Unsupported operand types in /var/www/com.example/www/html/wp-content/plugins/wp-slimstat/wp-slimstat.
php on line 725" while reading response header from upstream, client: 50.xx.xx.72, server: example.com, request: "GET / HTTP/1.0", upstream: "fastcgi://127.0.0.1:53237", host: "example.
com"

In wp-slimstat.php on line 683 we have $search = array(); however if you look at line 725 you find $search += $value; where $value from the browsers data file. I’m not sure if the browser data is a string or an array, but this isn’t the correct syntax either way since you can’t += on an array. Should this be set at a particular index or just appended with $search[] = $value;?

WordPress 4.0.1
WP Slimstats 3.8.3
PHP 5.4.33
Nginx 1.6.2
spawn-fcgi 1.6.3
Centos 5.11

I take that back, += is valid for two arrays, and I it looks like it only happens intermittently. Makes more sense what you meant about the additional checks in the new version. FWIW, here is what I got in the debug log:

wp-slimstat.php

$value = unserialize($browsers[$value[3]]);
if ( !is_array($value)){
	error_log("VALUE: ".print_r($value, true));
	error_log("SEARCH: ".print_r($search, true));
}
$search += $value;

Error log –

VALUE:
SEARCH: Array
(
    [0] => Wget/1.16 (linux-gnu)
    [1] => ^wget/1\..* \(.*linux.*\).*$
    [2] => Wget/1.* (*Linux*)*
    [3] => 12551
    [6] => 1.0
    [7] => 1
    [9] => Linux
    [4] => wget
    [5] => wget
    [28] => true
)

PHP Fatal error:  Unsupported operand types in /var/www/com.example/www/html/wp-content/plugins/wp-slimstat/wp-slimstat.php on line 729" while reading response header from upstream, client: 50.xx.xx.xx, server: example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:53217", host: "example.com"

If it’s helpful to anyone I just changed the code to the following:

if ( is_array( $value ) ){
	while (array_key_exists(3, $value)) {
		$value = unserialize($browsers[$value[3]]);
		$search += $value;
	}
}

I’m having the same issue.

PHP Fatal error: Unsupported operand types in /home….wp-content/plugins/wp-slimstat/wp-slimstat.php on line 725

Worst, this is causing some of my pages not being reachable by google bot resulting in HTTP Error: 500

I’m ditching it for now.

As I said, it will be fixed in 3.8.4. Thank you for reporting this glitch. However it’s not a memory issue. The tracker requires no more than 10 MB of ram to track a page view. Try measuring things with p3 profiler.

As you say, it may be that the tracker takes 10 MB of ram… But there does seem to be a memory issue, i.e., that slimstat as a whole uses a whole huge lot of ram… It may be that in sharing limited ram with other things it is crowding itself out in some way…? Of course I don’t know, just trying to reason my way through the terrain a bit…

I’ve been using P3 for a while now, off and on… I don’t see that it shows memory/ram usage unless I am missing something, just load times for plugins… And my hosting folks are impeccable in my experience, so I trust the truth of what they have seen and reported, regarding slimstat’s ram usage…

So basically same two questions for me…

Will you respond to slimstat’s use of memory on the whole more directly, please…?

And how reliable will the stats be with the fix, re your suggestion in a prior post in this thread that stats could be affected by whatever is going on…?

Kind regards.

1) Slimstat requires about 10 MB to track a pageview, and from 10 to 60 MB to generate its reports, depending on your DB size.

1.5) I mentioned P3 so that you could see what is the load time added by Slimstat, to get an idea of how “heavy” (or slim!) this plugin is…

2) Stats will be reliable as usual, if all the files needed by the plugin can be loaded without any problems and are not corrupted.

Thanks for this… Coincidentally, I was just going to come here and report when you posted, I’ve been doing some experimenting, viewing some stats in slimstat and then going to cPanel and checking resource usage narrowed down for the time period, the last half hour in this case…

What I saw seems to confirm what you say here about memory usage… It is curious though and I would like to know what you think about the fact that my hosting folks when they reactivated slimstat on the site that was giving the error the error repeated, and then when they increased the memory limit the error went away…?

And even more that this now for me is something else I saw that is of concern and which I believe explains what my hosting folks maybe had more in mind when they said slimstat uses a “large amount” of resources…

During the exact time that I was viewing stats in slimstat, switching through different modalities, CPU usage went from basically zero to over the top… When I say over the top I mean that CPU usage went to my allowed limit on my shared server and was held there, flat lined for pretty much the whole period of time that I was checking slimstat stats… My account gave me a report that my CPU usage had been limited, as well…

This is one of the features my hosting provides, each account is limited to a certain portion of CPU usage, so no one can slow another site down by overusing CPU, something I appreciate a lot… But we can slow ourselves down…

I’d like to hear something from you about CPU usage as well…?

Kind regards.

Thank you, doublesharp. You pointed into the right direction ??

When working with big datasets, developers usually have two options: use memory or use CPU. We are aware of the high CPU usage issue when accessing the reports, and some solutions are already in the works. Not sure when we will be able to fully implement them in Slimstat, though.

Fair enough… Up to me if I want the CPU usage… Not sure I do as is, but hearing that some solutions are in the works is encouraging… I reckon how well and when they are implemented will tell…

Be nice to hear how it goes, as things develop… I may just deactivate slimstat in the meantime… Somewhat torn, it is really nice to have it there…

Kind regards.

We won’t blame you, if you want to go with another solution ??

That’s big of you… ??