Overall security on Semi-Ded

[BulaRae]

I have moved over to the Semi-dedicated plan from a cheap shared host. After several years from them I learned the hard way why you get what you paid for. In the past several months I have had 6 of about 30 sites hacked from within the root of my shared server at the lame hosting company. The hackers successfully created tmp directories (e.g., called tmp16) in my sites.

I am assuming the semi-ded will be much less risky as #1 hackers won't usually pay $30/month, and #2, the number of accounts on a server is so greatly reduced that Jaguar would surely be able to determine who is up to no good if they have a bad apple.

Is my logic correct?

[BulaRae]

Also, what do load average numbers mean?

What is the difference between this:
load average: 1.45, 1.18, 0.98

and this:
load average: 2.41, 2.09, 2.26

[Ron]

I don't know about your hacker logic, but I can weigh in on the load average.

What is the difference in the examples you provided? Virtually nothing. Load average is a count of runnable processes on the queue, including those waiting for CPU and for I/O. A rule of thumb for a healthy machine has typically been 3 per processor, your machine probably has 8 CPUs so up to around 24 is probably OK. In the past I have seen my machine 4 CPUs get up around 25 before it start to lag noticably.
Rule of thumbs are not guarantees, other things can affect the machine's ability to serve up your sites.

The three numbers are load averages over the last 1, 5 and 15 minutes IIRC.

[BulaRae]

Hey, thanks Ron. So do you mean those loads are extremely minimal cuz they could show numbers up to 23.39, for example?

The smaller numbers are actually the load from my shared host this afternoon, the slightly higher numbers from my Jag semi-ded server. I guess I was expecting the other way around, at the very least. Before I set out moving 30 sites to the semi-ded I really want to make sure I've made the right choice.

I evaluated VPS and the sales people here actually convinced me to go with semi-ded.

[Gwaihir]

Yes, a load number of 2.x is indeed quite minimal.

I'm not entirely convinced the 3 per processor (core) rule of thumb has scaled to modern machines; the number of CPU cores has gone up faster than other resources over the last few years, so it may well need to be adjusted to account for other bottle necks such as disk I/O.

How it really works out depends a lot on the use and configuration of the specific machine, so you have to get to know your specific server before you can tell at what level you need to start worrying. I'd estimate that can turn out to be anywhere between 16 and 30.

[JPC-Masood]

Your hacker logic will not work here because we use suphp that does not require world writable folders meaning no other user on your server has write access to your files. So if your account gets hacked it would mean you are hosting vulnerable scripts yourself which can damage your own account only.

[BulaRae]

Sweet! That's what I wanted to know. Makes me feel much better! I can trust myself to manage the security of my sites but the hacking that was going on across their servers was horrible. I have 4 other clients who have their own hosting accounts with them and they all got hacked the same way, even with just basic straight and simple HTML sites.

[Ron]

I'm not entirely convinced the 3 per processor (core) rule of thumb has scaled to modern machines; the number of CPU cores has gone up faster than other resources over the last few years, so it may well need to be adjusted to account for other bottle necks such as disk I/O.

Could be. But it's close. Maybe too low, as I mentioned from my anecdotal empirical evidence on my machine, up to about 25 before things get too slow. (Remember that the RoT was for a "healthy" machine, expected to have immediate headroom for short spikes.)

It automagically takes into account disk I/O as processes waiting for I/O are included in the "load average." It worked on systems that had 2-12 physical CPUs with varying amounts and configurations of DASD from million-dollar EMC boxes to large and small SCSI drives. I don't know if processes waiting for NIC resources are included, but I'd suspect they stall and are counted. Could be wrong.

Comparing the old machine's load average to the new machine's load average is problematical; we'd need to know about the old environment, but it really "isn't interesting" at this point, now that you're here at the best.

[Gwaihir]

I am thinking 3 is likely to be too high nowadays. Yes, I/O is included in the load average, but the rule of thumb hangs on the machine being "balanced" in the expected way. So, for its 8 "units of CPU core" it should have an equal "8 units of disk I/O power", "8 units of network transfer capability", etc. (Yes, as AFAIK all forms of I/O are counted; it's simply whatever makes a thread wait.) That's not the way hardware has developed recently; the number of cores has recently grown much faster than the average machine power.

It's also all asuming we're talking about machines that were expertly built for their task. Perhaps his old host had some cheap ass server with a fast CPU as its only asset "because that advertises so nicely". Any machine with a serious single bottleneck could start slagging at loads of over 1, I believe.

Another presumption seems to be that less is always better. That's not true: there's no point in rigourously underselling a machine. It doesn't benefit the clients, it just costs the host money.

Anyhow, so much for the guesswork for now. Perhaps I'll get some fresh data to base my impressions on in upcoming months: I just started work on a website where the most requested dynamic page takes 100 requests / second at peak hours. I really wouldn't mind studying the intricacies of handling that for a bit .

[mattsiegman]

100 reqs / second, nice Caching is your friend. Also, profiling

[Gwaihir]

Not really, not there. Caching is extensively used throughout the site, but this specific functionality, a journey planner, is too dynamic. I'd love to learn more about what drives it, do profiling, etc. But so far - fortunately for the client - it works just fine, so my attention is directed elsewhere.

[Ron]

I dunno, Wim. If there isn't enough disk, response goes down, wait I/O goes up, load average goes up, and fast. If there's plenty of disk (and by plenty I mean enough controller and data bandwidth, and fast seek time not really physical platters) then CPU might be the issue. Remember, it's not used to diagnose a machine, just to say "yeah, this guy is healthy (or not)."

In addition to more CPU, Gigs and Gigs of RAM are the norm now, and I'd have to assume that almost every installation is using some form of read disk caching at a minimum, and faster CPU and broad backplanes with tons of memory... ahhh, these are the good old days.

I think it just magically adjusts; the RoT has been around for about 2 decades.

If you've had some anecdotal experience where 2 is a better multiplier, I'd love to read about it!

[BulaRae]

Ok, so Argonaut is showing this for load right now: 84.86, 39.95, 17.36

And it's hanging big-time. That does not make me feel very good about my move to JPC and SPX! Plus it went down the other day, the day after my migration. Even on my old cheap, skanky host the server probably only went offline twice in several years that I experienced during business hours.

WTH?

[JPC-Rizwan]

The problem script/user on Argonaut have been disabled to stabilize the server. It is being monitored further for any other abusive scripts/users causing issues.

[Vin DSL]

The problem script/user on Argonaut have been disabled to stabilize the server. It is being monitored further for any other abusive scripts/users causing issues.

Bwahahaha!

Sic 'em, Rizwan!!!