We’ve recently begun the recording of our monthly uptime with a third party monitor. This can be used as an uptime summary of our weekly reports – and to double check the validity of our uptime claims.
http://www.pingdom.com/reports/xbi89ux1pmgo/check_overview/?name=BLD+Hosting
VPS ID: 160 (BLD Hosting Shared Server)
This post illustrates total uptime for the mentioned server – and a breakdown of any downtime. This information should only be used by our shared hosting clients.
Uptime Report for 01/03/10 – 08/03/10
Uptime: 99.90%
Outages: 2
Downtime: 06/03/2010 12:30:39 AM to 06/03/2010 12:34:39 AM, 05/03/2010 11:13:00 PM to 05/03/2010 11:21:39 PM
Total Downtime: 12 minutes, 39 seconds
Uptime Chart
Response Time Report for 22/02/10 – 01/03/10
Average Response Time: 60ms
Slowest Average: 62ms
Fastest Average: 59ms
Response Time Chart
VPS ID: 160 (BLD Hosting Shared Server)
This post illustrates total uptime for the mentioned server – and a breakdown of any downtime. This information should only be used by our shared hosting clients.
Uptime Report for 22/02/10 – 01/03/10
Uptime: 99.98%
Outages: 1
Downtime: 26/02/2010 11:22:52 PM to 26/02/2010 11:24:52 PM
Total Downtime: 2 minutes
Uptime Chart
Response Time Report for 22/02/10 – 01/03/10
Average Response Time: 59ms
Slowest Average: 62ms
Fastest Average: 57ms
Response Time Chart
VPS ID: 141 (Customer VPS)
This post applies to a customer VPS (Virtual Private Server) and is separate from BLD Hosting and its servers. This post should be used as a news feed for the mentioned customer.
Forced reboot performed on VPS at approximately 4:30 PM (Server Time).
VPS ID: 141 (Customer VPS)
This post applies to a customer VPS (Virtual Private Server) and is separate from BLD Hosting and its servers. This post should be used as a news feed for the mentioned customer.
The cPanel License is now valid, and has been applied to the VPS’s main IP address.
VPS ID: 141 (Customer VPS)
This post applies to a customer VPS (Virtual Private Server) and is separate from BLD Hosting and its servers. This post should be used as a news feed for the mentioned customer.
cPanel software is now installed on the server with a trial license. The license will be processed within 24 hours, and will be updated soon.
VPS ID: 141 (Customer VPS)
This post applies to a customer VPS (Virtual Private Server) and is separate from BLD Hosting and its servers. This post should be used as a news feed for the mentioned customer.
VPS created on 22/02/2010 with CentOS 5.4
Server ID: CL-363 (Main BLD Server)
Affected Services: VPS-ID: 160 (BLD Shared Server), VPS-ID: 150 (Customer VPS)
Maintenance has finally completed, and the server is back online – running better than ever! Below is a detailed explanation of everything we’ve been working on over the last couple of days; and a breakdown of its role in the mentioned downtime:
The server Motherboard has been replaced
Overall Downtime: 1-2 hours
Plans to upgrade server memory (RAM) could not be fulfilled until we installed the new motherboard – as our previous one could only support a maximum of 4 GB. This will also rectify our ongoing packet-loss problem.
Added an additional Hard Drive
Overall Downtime: 0 hours
Added an additional hard drive for internal use.
Increased server RAM by 100% (It is now 8 GB)
Overall Downtime: 0.5-1 hour
We’ve upgraded server memory to 8 GB from 4 GB. This should considerably increase performance for all customers and their subsequent visitors.
Reloaded Operating System
Overall Downtime: 1-2 hours
The operating system was reloaded as a direct cause of the Motherboard upgrade. If this had not been done, the kernel would have failed due to the sudden influx of new devices, and the lack of their corresponding drivers.
Backup and transfer of Backups
Overall Downtime: 19 hours
Naturally, reloading the operating system required the wiping of all files that were present on the server. We needed to run a full system backup, move it to a safe location, wait for the operating system to be reloaded, and transfer the backups again – at which point we’d begin recreating user accounts. Packaging and transferring the backups are what caused most of the downtime during server maintenance – the transfer of hundreds of GB’s of data is not exactly the quickest of operations.
We’ve just finished tuning the server, installing necessary services, and taking care of loose ends. Although the server has been up for over 48 hours, we decided to post up a detailed explanation as soon as everything had been taken care of. At this point, everything should be running fine – and much, much smoother.
Total downtime lost to Server Maintenance was ~24 hours.
As we mentioned in a previous post, we were expecting a new Motherboard last Friday. The Motherboard will be used to upgrade the amount of RAM on our main server (Server ID: CL-363).
However, recent weather conditions around our DC (Scranton, PA, US) have caused a delay on our sipment. Here is the message we received from our DC on Friday:
Hi Andrei,
We had a major snowstorm here in the north east U.S. on Wednesday. Subsequently, shipping had been delayed. I’ve tracked the packages and they are arriving on Tuesday evening. Once we are ready for the motherboard swap, I’ll shoot over a message and wait for you to confirm before we proceed.
Thank You,
As mentioned in the message, the shipment is now expected to arrive on Tuesday.
Server ID: CL-363 (Main BLD Server)
After working to mitigate our packet loss problem, it resurfaced today – this time, for a much more extended period of time. Our previous attempts to control the packet loss problem have failed.
Here’s a ping of the server during packet loss:
ping: 204.124.183.213
Location Result min. rrt avg. rrt max. rrt IP Singapore, Singapore: Packets lost (70%) 268.7 273.3 282.3 204.124.183.213 Amsterdam2, Netherlands: Packets lost (90%) 87.8 87.8 87.8 204.124.183.213 Florida, U.S.A.: Packets lost (90%) 42.2 42.2 42.2 204.124.183.213 Amsterdam3, Netherlands: Packets lost (90%) 86.3 86.3 86.3 204.124.183.213 Hong Kong, China: Packets lost (80%) 249.6 250.0 250.4 204.124.183.213 Rio de Janeiro, Brazil: Packets lost (100%) 204.124.183.213 Sydney, Australia: Packets lost (90%) 242.1 242.1 242.1 204.124.183.213 Munchen, Germany: Packets lost (90%) 112.8 112.8 112.8 204.124.183.213 Cologne, Germany: Packets lost (90%) 89.8 89.8 89.8 204.124.183.213 New York, U.S.A.: Packets lost (100%) 204.124.183.213 Stockholm, Sweden: Packets lost (100%) 204.124.183.213 Santa Clara, U.S.A.: Packets lost (100%) 204.124.183.213 Vancouver, Canada: Packets lost (80%) 89.5 90.3 91.1 204.124.183.213 Krakow, Poland: Packets lost (100%) 204.124.183.213 London, United Kingdom: Packets lost (100%) 204.124.183.213 Madrid, Spain: Packets lost (90%) 99.3 99.3 99.3 204.124.183.213 Padova, Italy: Packets lost (90%) 140.7 140.7 140.7 204.124.183.213 Austin, U.S.A.: Packets lost (100%) 204.124.183.213 Amsterdam, Netherlands: Packets lost (90%) 116.2 116.2 116.2 204.124.183.213 Paris, France: Packets lost (90%) 100.3 100.3 100.3 204.124.183.213 Melbourne, Australia: Packets lost (100%) 204.124.183.213 Shanghai, China: Packets lost (90%) 270.0 270.0 270.0 204.124.183.213 Copenhagen, Denmark: Packets lost (90%) 93.2 93.2 93.2 204.124.183.213 Lille, France: Packets lost (80%) 96.3 96.4 96.5 204.124.183.213 San Francisco, U.S.A.: Packets lost (90%) 86.4 86.4 86.4 204.124.183.213 Zurich, Switzerland: Packets lost (100%) 204.124.183.213 Mumbai, India: Packets lost (90%) 294.5 294.5 294.5 204.124.183.213 Chicago, U.S.A.: Packets lost (100%) 204.124.183.213 Johannesburg, South Africa: Packets lost (100%) 204.124.183.213 Nagano, Japan: Packets lost (90%) 194.2 194.2 194.2 204.124.183.213 Haifa, Israel: Packets lost (100%) 204.124.183.213 Auckland, New Zealand: Packets lost (90%) 210.0 210.0 210.0 204.124.183.213 Antwerp, Belgium: Packets lost (100%) 204.124.183.213 Groningen, Netherlands: Packets lost (90%) 97.4 97.4 97.4 204.124.183.213 Moscow, Russia: Packets lost (100%) 204.124.183.213 Dublin, Ireland: Packets lost (100%) 204.124.183.213 Oslo, Norway: Packets lost (100%) 204.124.183.213 Odessa, Ukraine: Packets lost (90%) 132.6 132.6 132.6 204.124.183.213 Manchester, United Kingdom: Packets lost (100%) 204.124.183.213 Vilnius, Lithuania: Packets lost (90%) 164.5 164.5 164.5 204.124.183.213
This time, however, we took our time – and after a long chat with our DC – have concluded that the NIC card is to blame. Once the problem was diagnosed, we had the card switched immediately and are expecting the packet loss problem to be rectified.
Downtime during packet loss and NIC card replacement reached a total of about 1 hour and 30 min. This problem has been causing us a whole load of troubles – epecially for our uptime – over the last week or so. Hopefully things will clear up with the new NIC card.
