Piotr GRD

And this is exactly what I am describing - these numbers are the average numbers of processes waiting either for the CPU share or to access the disk to load or write some data. Third number mentioned by you represents the average number of processes for the last 15 minutes. While the images on the forums won't be reloaded every minute by most of the people I think that displaying average for longer time is a good choice made by the person that created it. Seeing a temporary 1 minute peak while 1 minute before and 1 minute later server load is low and fine could be misleading. On the other hand on my graphs you can view the 24 hours history, so viewing such short 1 minute peaks can be sometimes useful. Some can be missed, though, as I query the servers every 2 minutes, but anything significant will be reported by the numbers of average load for longer time periods (5 and 15 minutes). edit after seeing xaav's reply: ... I think that displaying average for longer time is a good choice made by the person that created it, especially if the retrieved from server value is cached.

So called "server load" is the average number of jobs (processes) in the run queue (waiting for CPU share) or waiting for disk I/O (load/write the data). So we can simplify it and describe as CPU and I/O utilization on the server. Inside of cPanel you'll find the average server load for last 1 minute, the tool displayed as the images on the forums uses the value average for last 15 minutes, if I'm right. And on provided by me server monitor you can find graphic presentation of three values - average for last 1, 5 and 15 minutes, so all that are reported by the server itself (well, 2 servers in here).

Just for your information: ns2.heliohost.org still has no records for algalil.heliohost.org, while ns1 has.

Yes, since July 5th 2011 there are two separate nameservers. Previously it was physically only one. Having one was less reliable (if one fail - everything fail - especially if it's on the same machine with overloading everything Johnny), but no need to synchronising anything. Having two is better for reliability, but problems with synchronising the entries on it appear - as we can see for the second time within these 40 days already.

My guess would be that it's because of ns2 being intermittently unavailable. And if such temporary "downtime" happend at the time when DNS records for new added domains/subdomains are trying to be synchronised between two nameservers - the process fail. I may be wrong, of course. I can not be sure how exactly the process of synchronising the DNS records on both nameservers works. If I'm right - solution would be either makes the ns2 more stable or doing a full sync of zones from time to time. Second solution may consume too much resources, though, depends on the number of domains and subdomains hosted. As I wrote before, when there was only one (physically) nameserver - having physically two nameservers is much better for reliability, but process of synchronising them may be painful, depends how many DNS records are stored.

All the records on HelioHost nameservers are fine and - as you can see by yourself - both domains works properly. The error may be either because of your registrars server for some reason can not access HelioHost nameservers to check for the existence of the valid records on it OR because it's one of the registrars that fully accept only the "confirmed" in some way nameservers. OR maybe something else unknown for me. As long as the registrar does not block you from using these nameservers for your domain names and everything works you may simply ignore this error (I assume it's visible only for you after login at your registrar). I remember that in the past one of my registrars did accept only such "confirmed" nameservers, too, but all what I needed to do was add these nameservers to the registrars list, process was fully automatic, my personal "confirmation" that these nameservers are valid was enough. Of course it may be completely different at various registrars. EDIT: Oh! That's not really a domain registrar, but just a place where you can get free (sub)domains. In that case simply ignore this error, really, as long as everything works.

If the user was aware of the problem with all accounts displaying his/her content, if he/she knew that the webhost admin has created the "technical difficulties" page and he/she did replace it with ads on purpose - well, maybe, but even if then I would have doubts, that's not his/her fault that all accounts did display the same content, right?... If the user was not aware of the problem, if he/she didn't knew that the admin created the "technical difficulties" page (does the admin even tried to contact with that user and ask him/her to temporarily do not edit this page?...), if he/she simply worked on his/her website - I'll let myself to completely disagree with you.

I remember similar situation (unfortunatelly I can not find that topic about it) when all accounts did show content of one specific account, then one of the admins suspended it, so all accounts did show as suspended. Later djbob wrote that it wasn't that users fault, but some other error appear. jje, I'm not saying that this is the case, but don't you think it's possible that the user just worked on his/her website at the moment with not being aware at all that all accounts display his/her content for some reason?

Yes, after seeing the -> 8th August <- and -> 9th August <- when Johnny didn't work at all and the following days when Johnny did start working again we can be sure that: a ) Johnny does affect the whole physical server with main heliohost / helionet and ns2 on it; b ) sometimes (ie. 9th August, 3 times) there are some problems unrelated to the load made by Johnny.

They (Hurricane Electric) have a Twitter account where they posted: http://twitter.com/#!/henet/status/100203056502816769 From a quick search, ie. on webhostingtalk.com, I can see that they have problems with power outages every now and then. The other company that I know with the same frequent problems with power is BurstNET Technologies. After all such power failures there are often problems with not all servers booting up properly. Even if the power outage is short (by looking at my monitoring results I think it was something around 22 minutes or so, but I may be wrong) the server may boot up properly and instantly OR may need intervention of the technician in the datacenter. And the time depends on how many technicians are there, how many servers they have to handle with and how much other things to do they have, does they check all the servers by themselves or do anything only on a support request of the server owner. The last thing is the queue, what priority the specific server has. If what byron wrote is true, then obviously HelioHost servers will be far far at the end of the queue of things to do / servers to manually restart in such situations.

All you did is irrelevant. That's server-wide problem for all accounts on Stevie. This happend in the past, this happend 2 days ago for little less than 7 hours, this happend today, again. @ admins I have just spot it. The time of the day when it start to happend. Today - July 28th - it started ~08:08 UTC (~01:08 PDT). 2 days ago - July 26th - it started ~08:06 UTC (~01:06 PDT). 20 days ago - July 8th - it started ~08:08 UTC (~01:08 PDT). So I think it's worth to check it. Possibly it's unexpected and unwanted result of something that is scheduled for that time?...

It should work OK. I do monitor accessibility of the server with my pages, too, and I see no problems with it. I'm aware of the very short (1-2 seconds) temporary issues, though, that could happend from time to time, but it's rare. However if for someone, anyone, there will be some longer problems with accessibility to my pages - send me an email or a private message about it.

Everything should work properly even if you use external nameservers as long as you'll create a proper "A" or "CNAME" record for the selected subdomain on these nameservers. It can be either the "A" record pointed to the same IP as the records for your root domain and www subdomain or "CNAME" pointed to your root domain name or any other domain/subdomain that is pointed to the same IP on HelioHost. The choice is yours. I would choose more reliable nameservers. I don't know anything at all about reliability of Yola nameservers, but ns1.heliohost.org works well while ns2.heliohost.org not so well.

@ Krydos I think that you mean: PST in Winter and PDT in Summer (and not PST all the time) - and this is what I have set in a day after your post. @ Tjoene I don't really want to play with this. Currently 1px wide on the graph is one test done every 2 minutes, 720px represents 720 tests done within 24 hours. It looks good in 1024px resolution, but I am aware that it's little bit to small for bigger screen resolutions. However I don't really want to play with this. But you may try to use your browser in-build functionality. I'm not sure the other browsers, but modern versions of Firefox (3.0 and above) handle quite well the scaling of the websites content, so you can click CTRL + +(plus) on your keyboard to enlarge the content and CTRL + -(minus) to reduce the size, CTRL + 0(zero) to reset to default size.

All accounts on the server "Stevie" does not work for ~5 hours already (at the time of my post) and redirects to "account queued" page for main URLs (ie. stevie.heliohost.org/ ) and to 404 for all the other URLs (ie. stevie.heliohost.org/page.php). This happend from time to time, unfortunatelly. You may see that even frame with twitter events above the forum is "404" currently and you can check this section of the forums: http://www.helionet.org/index/index.php?showforum=81 for many the same looking posts. So check your account when this issue - global for all accounts on Stevie - will be fixed (again).

Changes: At 27th June 2011, Monday, the URL of the service has been change: http://grd.net.pl/heliohost/monitor/ => http://heliohost.grd.net.pl/monitor/ Update your links and bookmarks, please. Thank you. Since 2nd July 2011, Saturday, new functionality has been implemented. The graphs display now average server load for Stevie and Johnny servers. The look of it may change a little bit to improve readability if will be necessary. Thank you to the person that gave me an idea for this implementation (quite long time ago) and the second one that unintentionally hastened me little bit to finally do this. : ) Since 3rd July 2011, Sunday, I have added the second time line in different time zone. Apart of Coordinated Universal Time (UTC) the time is displayed now in EST in Winter and in EDT in Summer, which reflects to the time used in example in New York. I am, personally, in Europe, so it's not for me, but for convenience of users in America. If you think that for majority of users different time zone will be more useful and/or more convenient - please, suggest one. HelioHost Server Monitor

I don't know if that was only one, that's why I wrote that access to at least one of the Stevie's IPs - 216.218.192.170 (my test account on Stevie is on it) - was blocked, while access to 65.19.143.2 (main one for stevie.heliohost.org) was fine. I didn't check any other Stevie's IPs apart these two. I have checked from various locations, so it's not that just I was blocked. And that was very first time that I did notice such situation. It was for 2 or 3 hours only. At the time of my post it was already fine (aka. back to being intermittently slow, but accessible).

I don't know what you did, but for some time access to at least one of Stevie's IPs - 216.218.192.170 - was blocked (it didn't answer even for a ping) while access to 65.19.143.2 was fine. But I guess you may know this already. Back on the topic... I am not a hardware expert, but maybe network card or something else of this kind is broken and can not handle more than X connections or limits transfer speed which cause the slow responces while not generating server load. Pure guess work.

DNS issue has gone, so you're one step further. Redirection to "account queued" is another problem and with this one I am not able to diagnose why it could be. As to why you still did see that the page does not exist: remember about cache, either cache of your browser (temporary internet files) or DNS cache, which may sometimes cause that for some time you'll still see previous version even after changing something.

At the moment the DNS entries for wideaperture.heliohost.org are already present on HelioHost nameserver - while these were not couple of hours before. Similar problem was here and seems to be fixed, too: http://www.helionet.org/index/index.php?s=...ost&p=66623 So it looks that something has been done. (Maybe some kind of reset or whatever djbob done while testing Charlie's power usage was enough.)

At the moment the DNS entries for femaleonly.co.cc already are present on HelioHost nameserver. The same happend for mentioned in here http://www.helionet.org/index/index.php?s=...ost&p=66443 wideaperture.heliohost.org, so it looks that something has been done. (Maybe some kind of reset or whatever djbob done while testing Charlie's power usage was enough.)

femaleonly.co.cc does point to ns1/ns2.heliohost.org nameservers. But HelioHost nameservers does NOT have any records for femaleonly.co.cc, so the reason of problems seems to be really on HelioHost side. I can not check if the server does accept requests for femaleonly.co.cc at all (bypassing the DNS system) as Johnny is not accessible at all at the moment and still existsing on HelioHost nameservers records for femaleforum.eu suggest that Panos80's account is on Johnny. Tip for people trying to help in such cases: apart of "whois", using "dig" could be good idea, too. : ) PS. Similar situation with working account but with no DNS records created on HelioHost nameservers has been mentioned in here: http://www.helionet.org/index/index.php?s=...ost&p=66443

Quote: ...Resolved itself overnight.... This is what I wrote about having to wait for DNS changes, cached copies of them having to expire etc. As for the proper grammar part - I am not sure what you mean, as English is not my native language, I didn't even take any lessons of it, so I don't know at all if either your or my posts are correct or not in this matter (most probably my is not best and if so - sorry).

Quote: ... then I have to add 2 new NS records(ns01.heliohost.org, ns02heliohost.org) in my ns space from domain DNS settings and ... No. Currently you use the following nameservers: hndservers.earth.orderbox-dns.com hndservers.mars.orderbox-dns.com hndservers.mercury.orderbox-dns.com hndservers.venus.orderbox-dns.com Can you add any A/CNAME/MX/etc. records in there? If so, then just like you have created all the A and CNAME and MX records in there, create another "A" one for service.impaki.net that will point to the IP of your HelioHost account (found in cPanel). You don't have to use HelioHost nameservers at all. I, personally, don't even recommend it as recently HelioHost nameservers have low uptime (you can check my monitor, link in signature) which would make your subdomain being unavailable for visitors, even if the hosting server would be available. Of course on the HelioHost side you need to add service.impaki.net as the add-on or parked domain (unless it is set already as the main one).

Currently you use the following nameservers: dns1.registrar-servers.com dns2.registrar-servers.com dns3.registrar-servers.com dns4.registrar-servers.com dns5.registrar-servers.com And these nameservers points your domain name to 174.109.... IP where I see Drupal installation. Remember that DNS changes are not instant, especially if you change the authoritative nameservers for your domain. It's just most probably the cached copies of DNS records are working for you, your computer, your ISP etc. I didn't call your domain name ever before, I had no cached copies of your DNS entries anywhere on my computer or at my ISP, so I've just accessed the entries from original source. But you did call your domain when having it pointed to HelioHost and these cached entries are still working for you (on your computer, at your ISP etc.) and you have to wait until these cached entries will expire so you'll get them again from original source. After changing the nameservers you have to always remember that it may be even 24-48 hours before the changes will take a place on the whole world. Usually faster, but anyway, all cached copies of previous DNS entries have to expire everywhere before. So if you ever want to have instant switch between the hosts - keep the same nameservers and play around only with A records while having low TTL set for them. You can always check the crrectness of your DNS settings - even if not propagated everywhere, yet - with using "whois" and "dig".