How much power would a basic home server use?

Forums › Desktop computing › How much power would a basic home server use?

1 | 2 | 3

867 posts

Ultimate Geek

#990486 19-Feb-2014 14:20

Since people are suggesting a laptop, what about installing a linux distribution with MySQL on a Chromebook?

#include <standard.disclaimer>

andrewNZ

2487 posts

Uber Geek
Inactive user

#990487 19-Feb-2014 14:22

What about your internet connection? it might be a significant bottleneck itself.

KiwiPower

18 posts

Geek

#990519 19-Feb-2014 14:55

andrewNZ: What about your internet connection? it might be a significant bottleneck itself.

The 6 seconds I mentioned is the time taken locally at 100Mbps for the server to respond. Once the page starts loading it loads instantly. It's the "Waiting for..." that takes 6 seconds.

My connection speed is 8 down 1 up and 12ms to Auckland. Sadly I'm outside the UFB upgrade area so that'll be my speed for all eternity. But I don't let that stop me.
https://www.speedtest.net/result/3034560010.png

I compress any pictures I put on pages so that they can be uploaded in a second or less at 1Mbps.
1Mbps is about 125KB/s so I keep pictures to about 40KB using lightroom and they load instantly.

I've accessed the site using 4G from abroad and don't notice any difference in how long the page takes to load. It's the "Waiting for..." that takes all the time. I've watched the CPU usage using the top command and the CPU is maxed out for 6 seconds during the "Waiting for..." and then the page loads in a blink.

ubergeeknz

3344 posts

Uber Geek

Trusted

Vocus

#990521 19-Feb-2014 15:00

Oh and it's Wordpress right? So the first place to look (after moving your DB to SQLite) should be plugins... some of these suckers are very inefficient and slow things down a lot. Killing some plugins got my site from an 11s page load time down to about 3s.

KiwiPower

18 posts

Geek

#990525 19-Feb-2014 15:04

ubergeeknz: Oh and it's Wordpress right? So the first place to look (after moving your DB to SQLite) should be plugins... some of these suckers are very inefficient and slow things down a lot. Killing some plugins got my site from an 11s page load time down to about 3s.

It has taken that long to load before I started using any plugins but if you want to know I'm currently using:

Akismet
Who Hit The Page - Hit Counter
WordPress Hit Counter

Can you run through what I lose in mysql lite?

KiwiPower

18 posts

Geek

#990538 19-Feb-2014 15:12

The process maxing out the CPU is www-data, mysql process is hardly using the CPU it's only hogging memory.

ubergeeknz

3344 posts

Uber Geek

Trusted

Vocus

#990539 19-Feb-2014 15:13

KiwiPower:
ubergeeknz: Oh and it's Wordpress right? So the first place to look (after moving your DB to SQLite) should be plugins... some of these suckers are very inefficient and slow things down a lot. Killing some plugins got my site from an 11s page load time down to about 3s.

It has taken that long to load before I started using any plugins but if you want to know I'm currently using:

Akismet
Who Hit The Page - Hit Counter
WordPress Hit Counter

Can you run through what I lose in mysql lite?

There's a plugin here - as far as I can tell you lose nothing. SQLite is simply much leaner than MySQL so it will use less resource on your Pi. Looks like you'll need to build a new instance with this plugin in play (read the instructions at the plugin page itself) then move your content across.

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

TwoSeven

1624 posts

Uber Geek

Subscriber

#990666 19-Feb-2014 18:09

ubergeeknz:
KiwiPower:
ubergeeknz: Seriously though, why do you want to host it yourself, when there's plenty of cheap and reliable web hosting out there with redundant connectivity, power, etc. and fully managed?

Where's the fun in that?

You have a point. However I'd look into optimising things a bit before shelling for new hardware, sort out why MySQL is using so much RAM and whether you can reduce it, why page renders are taking so long, see what fat you can trim in terms of other things running on the box, etc. You'd be surprised (especially with low powered devices) how much you can squeeze out with some optimisation. The suggestion of ditching MySQL and going to SQLite may be a good place to start. Oh and something like cloudflare to offload anything not needing dynamic updates.

MySQL isn't really the issue I don't think - given the memory foot print. Your current device appears by the description to be I/O constrained - I suspect better performance might be achieved by replacing the HD with an SSD and run a larger swap file. On top of this one can increase the memory aperture (its a technical way of saying out more ram in).

The query engine in a database is not really that much of an overhead as such - more so I would suggest that the main tuning factor is "distance to the data". A mechanical drive has a latency way higher than an SSD and assuming one is using Sata III, a higher number of IOPs.

Hence my feeling is probably an SSD to see what kind of improvement can be gained and at least that can be taken to any new system.

I don't know what the size of the database is, but you could consider an experiment using either an SDHC card or a USB memory stick (in a USB slot) since both are effectively SSDs (just in a slightly slower package). I don't know anything about the PI, but I am wondering if it is possible to install Linux on a USB memory stick and store your DB on an SDHC card - giving the ability to remove the normal HD from the system - at least it might reduce power a bit.

Software Engineer
(the practice of real science, engineering and management)
A.I. (Automation rebranded)
Gender Neutral
(a person who believes in equality and who does not believe in/use stereotypes. Examples such as gender, binary, nonbinary, male/female etc.)

...they/their/them...

deadlyllama

1264 posts

Uber Geek

Trusted

#990746 19-Feb-2014 21:16

TwoSeven:
MySQL isn't really the issue I don't think - given the memory foot print. Your current device appears by the description to be I/O constrained - I suspect better performance might be achieved by replacing the HD with an SSD and run a larger swap file. On top of this one can increase the memory aperture (its a technical way of saying out more ram in).

The query engine in a database is not really that much of an overhead as such - more so I would suggest that the main tuning factor is "distance to the data". A mechanical drive has a latency way higher than an SSD and assuming one is using Sata III, a higher number of IOPs.

Hence my feeling is probably an SSD to see what kind of improvement can be gained and at least that can be taken to any new system.

I don't know what the size of the database is, but you could consider an experiment using either an SDHC card or a USB memory stick (in a USB slot) since both are effectively SSDs (just in a slightly slower package). I don't know anything about the PI, but I am wondering if it is possible to install Linux on a USB memory stick and store your DB on an SDHC card - giving the ability to remove the normal HD from the system - at least it might reduce power a bit.

Yes, SD cards and USB sticks are SSDs. But they often have terrible performance. Just because you can write a photo to one quickly (a nice big sequential write) doesn't mean using it as your OS drive, let along the backing store for a database, will be a good idea. Try a USB hard drive, or better still, a "real" SSD in a USB enclosure.

TwoSeven

1624 posts

Uber Geek

Subscriber

#990889 20-Feb-2014 08:46

deadlyllama:
TwoSeven:
MySQL isn't really the issue I don't think - given the memory foot print. Your current device appears by the description to be I/O constrained - I suspect better performance might be achieved by replacing the HD with an SSD and run a larger swap file. On top of this one can increase the memory aperture (its a technical way of saying out more ram in).

The query engine in a database is not really that much of an overhead as such - more so I would suggest that the main tuning factor is "distance to the data". A mechanical drive has a latency way higher than an SSD and assuming one is using Sata III, a higher number of IOPs.

Hence my feeling is probably an SSD to see what kind of improvement can be gained and at least that can be taken to any new system.

I don't know what the size of the database is, but you could consider an experiment using either an SDHC card or a USB memory stick (in a USB slot) since both are effectively SSDs (just in a slightly slower package). I don't know anything about the PI, but I am wondering if it is possible to install Linux on a USB memory stick and store your DB on an SDHC card - giving the ability to remove the normal HD from the system - at least it might reduce power a bit.

Yes, SD cards and USB sticks are SSDs. But they often have terrible performance. Just because you can write a photo to one quickly (a nice big sequential write) doesn't mean using it as your OS drive, let along the backing store for a database, will be a good idea. Try a USB hard drive, or better still, a "real" SSD in a USB enclosure.

The original premise is to reduce power consumption and eek out more performance. Using the mico-drives is the lowest cost way of achieving this (to see if it works) before committing money to buying the uprated hardware, considering many people have an USB drive/SD card already. Basically what I am suggesting is test the architecture first before scaling it up.

...they/their/them...

deadlyllama

1264 posts

Uber Geek

Trusted

#990938 20-Feb-2014 09:33

TwoSeven:
deadlyllama:
TwoSeven:
MySQL isn't really the issue I don't think - given the memory foot print. Your current device appears by the description to be I/O constrained - I suspect better performance might be achieved by replacing the HD with an SSD and run a larger swap file. On top of this one can increase the memory aperture (its a technical way of saying out more ram in).

The query engine in a database is not really that much of an overhead as such - more so I would suggest that the main tuning factor is "distance to the data". A mechanical drive has a latency way higher than an SSD and assuming one is using Sata III, a higher number of IOPs.

Hence my feeling is probably an SSD to see what kind of improvement can be gained and at least that can be taken to any new system.

I don't know what the size of the database is, but you could consider an experiment using either an SDHC card or a USB memory stick (in a USB slot) since both are effectively SSDs (just in a slightly slower package). I don't know anything about the PI, but I am wondering if it is possible to install Linux on a USB memory stick and store your DB on an SDHC card - giving the ability to remove the normal HD from the system - at least it might reduce power a bit.

Yes, SD cards and USB sticks are SSDs. But they often have terrible performance. Just because you can write a photo to one quickly (a nice big sequential write) doesn't mean using it as your OS drive, let along the backing store for a database, will be a good idea. Try a USB hard drive, or better still, a "real" SSD in a USB enclosure.

The original premise is to reduce power consumption and eek out more performance. Using the mico-drives is the lowest cost way of achieving this (to see if it works) before committing money to buying the uprated hardware, considering many people have an USB drive/SD card already. Basically what I am suggesting is test the architecture first before scaling it up.

But most USB flash sticks and SD cards have terrible performance -- in fact, KiwiPower's current setup is probably using a slow SD card as his filesystem. Swapping one slow drive for another will not eke out any more performance, all it will do is mean you own two slow flash devices rather than one.

Here's a helpful article on the [url=performance characteristics of cheap flash drives The Raspberry Pi people themselves have run into this problem, which is why the NOOBS SD cards they sell are specially selected to have good random write performance, even though they're "class 4". The Samsung SD cards are supposed to be better than most for this sort of thing but they're hard to impossible to buy in NZ.

ubergeeknz

3344 posts

Uber Geek

Trusted

Vocus

#990971 20-Feb-2014 10:16

Can attest to this, I have a couple of Samsung 32Gb microSD class 6 and the write performance is phenomenal. You can buy them from dx.com... I haven't tested them with a Pi though

Also it seems like the Pi is being CPU constrained; but have you looked in top to see what the io wait % is?

KiwiPower

18 posts

Geek

#991482 20-Feb-2014 23:14

But most USB flash sticks and SD cards have terrible performance -- in fact, KiwiPower's current setup is probably using a slow SD card as his filesystem. Swapping one slow drive for another will not eke out any more performance, all it will do is mean you own two slow flash devices rather than one.

Here's a helpful article on the [url=performance characteristics of cheap flash drives The Raspberry Pi people themselves have run into this problem, which is why the NOOBS SD cards they sell are specially selected to have good random write performance, even though they're "class 4". The Samsung SD cards are supposed to be better than most for this sort of thing but they're hard to impossible to buy in NZ.

You're right I'm using a SD card (this is still an educational experiment not super high-tech) but the swap usage is 0B of about 100MB. So all I can gather from that is that everything it needs must be on the RAM? Or am I wrong in thinking that? If not then what is in that 320MB lol I always thought that was the whole database and it just writes back changes to the SD card.

KiwiPower

18 posts

Geek

#991494 20-Feb-2014 23:26

ubergeeknz: Can attest to this, I have a couple of Samsung 32Gb microSD class 6 and the write performance is phenomenal. You can buy them from dx.com... I haven't tested them with a Pi though

Also it seems like the Pi is being CPU constrained; but have you looked in top to see what the io wait % is?

I have had a look at the top command. The www-data process (command apache2) uses about 97% of the CPU during the long "Waiting for..." then it instantly drops back to nothing. So the CPU is definitely under powered for php, and mysql websites. That's why I was wondering what I could build that uses a little more power but has a lot more power and there has been some great suggestions on this!

The 320MB mysql process is using a lot of memory but the system swap usage is still 0B so it an't broke yet so I won't fix that at the moment. I'm probably more likely to break it fixing it. I read that there are some plugins that are broken with mysql lite on WordPress. I don't think any of my plugins are one of them but Murphy's law I'll find the best plugin on this earth and find it incompatible with mysql lite. If in the future it starts digging into the swap, then I'll do the switch. The biggest issue is the CPU time to process hits which is the www-data process not mysql. The memory usage is just a worry but not a problem at this stage.

TwoSeven

1624 posts

Uber Geek

Subscriber

#991604 21-Feb-2014 09:02

I am not a MySQL person, but most databases are ISAM systems - that is, they are just a file divided into blocks with a separate index pointing to the data in the blocks. In that regard, it is unusual for the database to be loaded into memory, instead reads and writes at the fibre (part of a thread) level are made.

So in answer to the question, what is loaded in memory, I suspect that it is likely to be things like the execution engine, partial index, cached data, configuration entries and other such things.

Using an MS Windows analogy, the 100% CPU usage in task manager doesn't always mean that the CPU is actually busy doing processing work, it tends to mean that the CPU is busy waiting for the I/O system to return the data. Typically in windows, one will see an I/O spike shortly after the CPU goes 100%.

From a database tuning perspective we need to be thinking - for each request for data, how long will the I/O operation take and where does it need to go to get it. When we say "distance to data" we are saying how long does it take the electrical signal of the I/O operation to get to the storage (execute any mechanical operations involved if a HD is used) and return. If its L1 cache, L2 cache, L3 cache, L4 Cache (RAM) or L5 Cache (hard disk) the response times will take longer the further the data is away. Add on top of this the processing requirements of the database to identify, compile and execute the query.

For in-depth analysis I would suggest that one needs to know the following values. The time at which the HTTP request was received from the browser, the time the data request is sent to the database, the time it was received back, and the time the response is sent back to the browser. This would given an indication as to whether the bottleneck is within the request processing (CPU) or data processing (database).

Just my thoughts.

...they/their/them...

1 | 2 | 3