March 13th, 2010
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
March 9th, 2010
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

March 4th, 2010
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

March 3rd, 2010
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).
March 3rd, 2010
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.
March 3rd, 2010
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.
March 3rd, 2010
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
February 21st, 2010
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.
February 15th, 2010
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.
February 9th, 2010
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.