MùPùF.org

Linux, Programming and Octopodes

--- *Projects* (website in development: svn r299)--- » PPassKeeper » ArduIDE

MuPuF's tech blog MuPuF's tech blog subscribe

MùPùF.org will change its serverMùPùF.org will change its server

in MùPùF.org
Tags: mupuf.orgovhserver

If you are often visiting mupuf.org, you may have noticed some down times. These are in general due to problems with one single weakness of the current dedicated server we use, the fact that / is stored on a distant hdd accessed through the network. Also, we were short of memory which lead us to some serious memory optimisation, sacrificing some services for the common good.
At the moment, we are using OVH's RPS1(fr).

As a replacement, I had been wondering whether to use the cloud or to go for a really expensive dedicated server. Both had pitfalls and I couldn't decide what to do.

Then, OVH launched a new kind of dedicated server, just 3€ more expensive than the RPS1 we already had. This new server is called Kimsufi 250G(fr) and we have decided to go for it!

Published Aug. 9, 2010 by read more
0

MùPùF.org: An awful weekMùPùF.org: An awful week

in MùPùF.org
Tags: cherokeemupuf.orgovhserver

You may know our server is hosted by OVH and is SAN-based. This means that the / of our server is not stored on a local hard disk drive but it is instead stored in a distant SAN. We already encountered "little" uptime problems because of some OVH service down-times. Well, last week has been the most horrible week ever[fr].

We had terrible throughput down to 70KBit/s, latencies up to 2 seconds and several down time that could have been as long as 8hours in a row.

On top of that, we had updates for the website that we could only apply by crossing our finger because some of them require the website to be rebooted. But, when rebooted, the django-based website touches a lot of files and with such a terrible latency, it could take up to 10 minutes to launch.

The problem was that cherokee was trying to spawn too many processes which in turn slowed down the website's boot sequence and this often lead the server to lack of RAM just as a bomb fork would operate.
I have fixed this problem by putting a lock on the beginning of the boot sequence.

A few hours ago, OVH switched our server to a new SAN which delivers close-to-normal performances. We are using this time to fix as many problems as we can. If you spot any problem, please send us a message.

Anyway, we are sorry for the inconvenience it may have caused.

Published March 3, 2010 by read more
0