Short lagspikes every now and then
~~![](<URL url=)http://i45.tinypic.com/opn1uf.png
This is kind of annoying and my guess is it is not really my fault (even though of course one can never be sure about that). What can i do on my side to be certain none of the local applications causes this (its very hard to cause packet loss plus nothing really changed when the problem started happening so i kind of doubt it is the local software) and what can be done to fix this?
This has been the case for more than a week now and I am not so confident anymore that it will simply disappear the same way it showed up.~~
1 Reply
@Hiruma:
What can i do on my side to be certain none of the local applications causes this (its very hard to cause packet loss plus nothing really changed when the problem started happening so i kind of doubt it is the local software) and what can be done to fix this?
It can be tricky with sporadic issues like this. I usually start with the assumption that it's something on the Liode and work outwards towards the host and/or network. For those Linodes where I have a long monitoring history, I may be quicker to assume it's external, but you never really know for sure without testing.
One way to do some local monitoring during such a period is over Lish - that's not using the networking stack on your Linode but a local (albeit virtual) console, so should be unaffected by the network, and maybe you can catch a spike in processing or some other issue over time. For very transient latency issues like this what I've also done in the past is just leave a background ping running to a known host (often another of my Linodes in the same DC) dumping its output to a file for a 24 hour period, to be able to observe latency over time. To help with the timing I usually put it in a small script with an infinite loop that dumps a date, pings for 60s, and repeats.
Then there's the question of isolating the Linode versus the network, and wide area versus local area. If you don't already have a second Linode in the same DC, provision one (you can delete it when done testing and get a prorated refund so don't need to spend on a full month) and then (a) do the same tests in parallel from your test host to both Linodes. You can also then do local testing between the two Linodes. If you see similar failures at the same time (and assuming the test Linode is idle versus tasks running on your regular Linode), it's less likely that it's your Linode itself.
Finally, if tests appear to point to the network or something outside of my Linode's control, I'll run some (low overhead) tests to the host machine. While the host doesn't guarantee a particular performance, if you see the exact same latency spike pattern from the host and at the same time as when you encounter it on your own Linode, it's a plausible indicator that the issue is common to the Linodes on that host.
Assuming that's the case, that's when I usually open a ticket and by providing the indication that the same problem shows up on the host as on my Linode (or across multiple Linodes if the earlier test showed that) is usually a good starting point to have Linode dig deeper into things.
Alternatively you could just open a ticket with what you have, but unless your host is being actively worked on for a networking issue (not impossible, but probably unlikely), it may be hard to get more than some generic suggestions back since at this stage the potential sources of the issue, and components involved, are very large with the data given. Although you may receive an offer to migrate to a different host just to see if that clears things up.
As a general comment, I will say not to hesitate to dig in further. It doesn't sound like something that should be happening (even if it's due to something under your control), and I've had several tricky sporadic network issues in the past, some of which took some real leg work to gather data, but in the end they all turned out to be actual issues that were able to be resolved.
– David