Ever increasing Physical Memory Usage since switching hosts

Hi,

I have a 1.54 cart upgraded from 1.50 for past 5 or so years. PHP 5.6. Add-ons Easy Populate, Zen Litebox, Image Handler4, and Edit Orders. And a third party template. I think that is it.

Last week my previous host had some issues so after a 24+ hour outage so switched back to a host that had previously hosted my site on for about a year. Am on shared hosting.

Under cPanel main page previously had usually seen 0 under Physical Memory Usage. Sometimes I would see a little usage usually something like 150 mb.

Since I switched back last few days Physical Memory usage keeps going higher and higher. This morning was around 400mb, now it's up to almost 600mb and I have never seen it that high before. On previous host when I checked CPU and Concurrent Connection Usage stats it averaged around 150-250 I think.

I put my site in Maintenance mode but this has no effect on memory usage. My site is in a subfolder under Public_HTML and when I take the site offline by changing the name of the folder to a random name the memory usage drops to 0. Change it back to correct name and instantly memory usage is back around 600mb. Checked and there are only one or two recent users online and maybe 10 recent spiders.

I sell used stuff like collectibles, stereo stuff, toys, books, games, etc. and consider the site to be "low volume". Average page views a day maybe 500-600, sometimes more or less. I do have a LOT of items online maybe 5000 and lots and lots of photos, and there are always a bunch of spiders crawling the site. The number of users and spiders has not increased recently. I haven't added many items recently.

Average bandwidth a month is usually 13gig.

Haven't made any major changes to site in quite a while and things had been going pretty smoothly except for some unrelated email problems. The site seems pretty slow and not sure if this is host or caused by memory issues. Currently am keeping it offline.

I think something may be seriously wrong and would very much appreciate any advice or suggestions.

Thanks.

cPanel main page does not normally show the information you are describing and if it does it is usually for the Server usage. As you have a Shared Hosting account your usage would be part of that.

With that said, there are many things one can do to increase site performance and I recommend using a tool like https://gtmetrix.com/. Signing up for a Free account is definitely recommended as you can keep comparisons of various dates, before and after you've made changes, to help you track what is working.

My cPanel does show that info. See attached photo. The Monthly Bandwidth Transfer of 30.72 KB is incorrect, not sure why.

And here is screenshot of 24 hours of CPU and Concurrent Connection Usage stats right after I changed the name of the folder, you can see how Memory Usage goes to zero right at the end of graph

There is probably no quick fix to current problems without doing Research. AwStats in cPanel can tell you more about site connections (perhaps someone is linking to your images or pages for example) and GTMetrix can tell where to make site improvements (perhaps images can be resized, is gzip turned on, and other good info).

Thanks Rob for the responses. I checked AW Stats and a few other reporting tools but don't see anything that stands out.

Put site back online and Physical Memory Usage stayed right under 600mb for about 10 hours or so, then made an abrupt drop to around 400mb, stayed there for a while before creeping up a bit.

I contacted hosting co. support and told them of my concern, just got the response "your website is working fine".

Starting to think my site may have always used been using a fair amount of memory and it just wasn't being displayed in cPanel correctly. Was concerned that something new was happening and there was an issue. and it would just rising up until it hit the 1024mb limit at which point might get cut off. But there seems to be a limit around 600mb. Maybe just the way server is set up and they are caching parts of my site, really have no idea just glad it's probably not an issue, hope it stays that way.

The difference in reporting of information could be related to slightly different architecture of the hardware behind it all, too. There are a lot of factors that could make the reported data between different servers show different, despite running so-called "identical" software. And it's possible that the server's core software may also be configured differently between servers, and that's impacting how your small "slice" of the server shows up in graphs. It may not actually affect performance at all. Or it might truly be indicative of a problem.

(If it were a dedicated server, then I'd inspect the MySQL ini configs to see how much RAM it's configured to consume, and look at other running processes to see if they're necessary or tuned properly. And other optimizations. But since you're on shared hosting, many of those are moot, and "likely" aren't driving those reported graph stats.)

Given that your host thinks things are fine (in theory they "should" know whether yours is "the same as" or "better than" the majority of other accounts on your server), use what you're observing now as a "baseline", and keep an eye on it periodically. Both you and Website Rob have been talking about this in your posts.

Just another 2cents worth...

Ted Grapler:

Under cPanel main page previously had usually seen 0 under Physical Memory Usage. Sometimes I would see a little usage usually something like 150 mb.

Since I switched back last few days Physical Memory usage keeps going higher and higher. This morning was around 400mb, now it's up to almost 600mb and I have never seen it that high before. On previous host when I checked CPU and Concurrent Connection Usage stats it averaged around 150-250 I think.

Personally, I'd be somewhat ignoring those reports. What you think is abnormally high is what I would consider ridiculously low for a zencart site - To be reporting such little memory usage would imply that the memory usage of the SQL server isn't being factored in - IOW, all you are seeing is the memory 'slice' being used by the webserver for your specific domain. A variance between different severs could be related to many things outside of your control such as the PHP version being used.

It can certainly be useful to keep a watch on reports such as this for 'baseline' purposes, and over time you will observe some kind of pattern to the usage -- For example, the memory usage may grow from 150mb to 800mb over a period of a week or so, or less, then it'll drop back to the 150mb and the cycle will repeat - perhaps not in the exact same way, but very similar... It can take a month or more to 'learn' this pattern before you'll be able to say with any degree of certainty that 'hey, something abnormal is going on here'.

Ted Grapler:

The site seems pretty slow and not sure if this is host or caused by memory issues.

No easy answer to this one I'm afraid, especially as 'host' and 'memory' can't be segregated in this manner - Not to mention that different folk have a different definition of what a 'host' actually is (technically, it is a machine, but many folk consider the person or company supplying the service as the 'host').

Cheers
Rod.

PS. If you were running a zencart site on a VPS, then unless you have at least 1Gbyte of memory then slowness is assured. Shared servers are a different kettle of monkeys though. :)

if your site is slow, as others have pointed out, use https://gtmetrix.com/ and correct those issues.

in my experience, the biggest slowdown is database access. you want to ensure that the server where your database resides is on SSDs as opposed to HDDs. solid state drives provide much greater speed and will make a huge difference in the performance of a ZC site.

note that some hosts can say they host using SSDs while putting your database on a server with HDDs.

if you have ssh access to the DB server, you can use the following code to test speed. a SSD drive will come back with results under 1 second:

time for i in `seq 1 1000`; do
    dd bs=4k if=/dev/sda count=1 skip=$(( $RANDOM * 128 )) >/dev/null 2>&1;
done;

good luck.

Thanks for the info carlwhat, RobG and DrByte.

Today the site seems speedy, tried while on the road from different ISP too and faster than usual. Don't have SSH access. I think will just check the cPanel Physical Memory Usage stats once a week or so instead of worrying about it unless the site is showing issues. In meantime working on a fresh install of 1.5.5e and transferring product and customer info over, setting up the look and feel, testing, etc.- have been putting this off for too long.

Those stats being shown by your current host (cpu, memory, concurrent connections) are because they are using cloudlinux with cPanel, which allows the hosts to set limits on all of those things and throttle a site that hit the limits.

CloudLinux OS is designed for shared hosting providers. It isolates each customer into a separate “Lightweight Virtualized Environment” (LVE), which partitions, allocates, and limits server resources, like memory, CPU, and connections, for each tenant. This ensures that tenants cannot jeopardize the stability of your servers, causing all sites to slow down or even come to a halt. CloudLinux OS also “cages” tenants from one another to avoid security breaches. This way, unstable scripts or malware are not able to sprawl across your customer sites, causing severe harm.

carlwhat:

in my experience, the biggest slowdown is database access.

Agreed. 100%

carlwhat:

you want to ensure that the server where your database resides is on SSDs as opposed to HDDs.
solid state drives provide much greater speed and will make a huge difference in the performance of a ZC site.

This one, I'm not so much in agreeance. Well, I do agree that SSD's provide a much greater speed in regards to disk access, but for best performance AKA 'huge difference', the key is in having enough memory to begin with - and if this is met then disk speed becomes a moot point.

carlwhat:

note that some hosts can say they host using SSDs while putting your database on a server with HDDs.

Possibly/probably. I've not come across any of them myself yet.

carlwhat:

if you have ssh access to the DB server, you can use the following code to test speed. a SSD drive will come back with results under 1 second:

time for i in seq 1 1000; do
dd bs=4k if=/dev/sda count=1 skip=$(( $RANDOM * 128 )) >/dev/null 2>&1;
done;

HHmm, will this work on a Windows based machine?   What if the server uses raid (/dev/md), or perhaps it is still using IDE drives (/dev/hd), or perhaps SCSI (/dev/sr)    -   OK, so I'm being a bit of a smartarse here ...but .. how does one know which drive the DB server is hosted on anyway?   What if the DB server is hosted on a different server than 'localhost'?  

*<comment removed>*

Cheers
Rod

RodG:

Agreed. 100%

This one, I'm not so much in agreeance. Well, I do agree that SSD's provide a much greater speed in regards to disk access, but for best performance AKA 'huge difference', the key is in having enough memory to begin with - and if this is met then disk speed becomes a moot point.

Possibly/probably. I've not come across any of them myself yet.

HHmm, will this work on a Windows based machine? What if the server uses raid (/dev/md), or perhaps it is still using IDE drives (/dev/hd), or perhaps SCSI (/dev/sr) - OK, so I'm being a bit of a smartarse here ...but .. how does one know which drive the DB server is hosted on anyway? What if the DB server is hosted on a different server than 'localhost'?

<comment removed>

Cheers
Rod
we can agree to disagree.

while you may not seen hosts that advertise SSDs and then host your database on HDDs, i have. which is why i bring it up.

as far as being a smartarse, indeed you can be. which makes is that more difficult to extract the good information you can provide.

as far as knowing which DB server your database is hosted on, i would look at the script:

includes/configure.php

and specifically at this constant:

define('DB_SERVER', 'localhost');  // address of your db server

as far as the provided code working on a windows system, please excuse me if i do not answer your questions to which you already know the answer.

best.

carlwhat:

we can agree to disagree.

Most definetly. I forget exactly what we were dissagreeing about though. Something about memory being faster than SSD's being faster than HDD's I think ;)

carlwhat:

while you may not seen hosts that advertise SSDs and then host your database on HDDs, i have. which is why i bring it up.

I really wasn't doubting you about this at all. Apologies If I made you tbink otherwise.

carlwhat:

as far as being a smartarse, indeed you can be.

I"d like to say I try, hard, but it actually comes naturally. Alas, it also gets me into a lot of potentially needless debates.

carlwhat:

which makes is that more difficult to extract the good information you can provide.

Or more often than not, makes it easy to miss a point that I intended to make.

carlwhat:

as far as knowing which DB server your database is hosted on, i would look at the script:

includes/configure.php

and specifically at this constant:

define('DB_SERVER', 'localhost'); // address of your db server

...  and here is where my point was missed...   The question/point was that there is no way to know which *drive* the DB server is using (ergo, making the test script you gave somewhat pointless), and even more pointless if the DB server was hosted somewhere other than "localhost".  This point further being that if the DB were "localhost" and assuming the website was hosted on an SSD (also "localhost") then it *could* be a reasonable assumption that the DB server would also be on the same SSD. (the assumtion being *probably* correct,  but not assured).  Putting it another way, if the DB server were anything other than "localhost" the script would be unusable/pointless, and if the DB server is "localhost" there could still be the situation that you describe (website on SSD, eg /dev/sda,  and DB on HDD, eg /dev/hda  (both localhost), but there would be no way for a user to determine this.
> **carlwhat:**
>
> as far as the provided code working on a windows system, please excuse me if i do not answer your questions to which you already know the answer.
To be perfectly honest, I really thougt that 'dd' was a *nix only command, and was actually quite surprised when I looked it up snd found that there was actually a windows version as well, so yes, I did know the answer before posing the question, but I felt it a valid question because for reasons I don't think I'll ever really understand, many folk/zenners still opt for a windows based server.   IOW, although neither of us said it outright, the script is really for *nix based servers only.

I was also subtely?  stating that the "dd" command itself was not one to be toyed with...  it can literally destroy a system.  This was not a reflection on you or the script you shared, but it IS one of the few commands that can have devasting results..  in fact I'd consider "dd" as being the most dangerous of all comnands, even durpassing fdisk (format disk for the uninitiated)

Cheers
Rod

.... and here we digress miles away from the issue at hand again. No longer has anything to do with Zen Cart or using Zen Cart.

Closing the thread.