I've noticed that, if my terminal is doing something like tail -f-ing a log with no input for a while, it will freeze. If I switch to the terminal and enter a key, eventually it will unfreeze and display whatever info should have already been displayed.

Does anyone know what causes this?

This doesn't seem to happen if the terminal is just sitting at a prompt.

Nobody else have this problem?

I'm running Gentoo. The one place where it always happens is when I 'emerge sync' and Gentoo is updating the files around 50%. It will stick on that number. If I hit a key, then after a couple minutes it will finally come back and give me a prompt.

Don't think that's a Linode issue... or an actual problem, to be honest.

I have multiple Gentoo boxes (2 servers, 2 workstations, 2 laptops, 1 Linode), and they all take a while around the 50-51% mark, then picks up again.

Seems normal. Annoying, but normal.

My emerge --sync is also slow on my Linode. It's down to the iotokens. When it stops keep an eye on /proc/io_status.

Could be, that's true.

strace -f'd the emerge --sync process and discovered that, around that time, it's heavily hitting /var/cache/edb/dep/usr/portage/kde-base-eclass.cpickle while it's processing /usr/portage/kde-base/*

cpickle is some sort of compressed or indexed database for Portage.

The one for kde-base is the largest single cpickle file; it's about 40x the typical cpickle size. It appears this is because of over 1,200 entries in kde-base... most others seems to have about 20-30 entries or so.

So it seems to be a combination of a) a lot of entries in the kde-base cpickle and b) a lot of I/O to it (though I don't think I remember running out of tokens for that on my Linode), c) a lot of entries = more time and CPU processing.

Bottom line: there's just a lot of stuff when it hits the KDE part of the Portage tree, so it takes a while to process all that stuff.

It's a lot faster doing it on my laptop with faster CPU than at Linode, so I think that ultimately, it's just that Linodes will simply take longer in this area and seem to "stall". I monitored I/O tokens usage throughout emerge --sync run on the Linode and don't remember running out or coming close.

But if you were already kinda low on I/O tokens when you ran the sync job, that could be enough to make things really slow.

On my Linode, I think the sync takes a few minutes to get past the 50-51% mark. On the laptop, about 30 seconds or so.

Yeah, all my machines get slow around that mark, but my linode never moves past it (as far as the terminal displays, anyway.)

If I press a key, then after a few minutes it will print out all the rest of the info in one dump. So, it's not that it just slows down at this point, the terminal also stops updating at all.

I'm having a hard time explaining this, so to be clear: the terminal will not continue past the 50-52% mark EVER, unless I hit a key. It also sticks in other places, too, like when I 'tail -f' some log. I will notice that the tail isn't refreshing, hit a key, and then a few minutes later the log will continue. Likewise, if I ctrl-C the tail, it will still be a few minutes before it quits.

Hmmmm.

That is indeed interesting. I'm afraid I'm not seeing the same thing, but then again, I'm not actively tail'ing or watching when I do that stuff... I'll have to try a few experiments.

I'm curious... what terminal application are you using? xterm, PuTTy? SecureCRT? Terminal? And what version? And what is the term/TERM env vars set to?

I'm using aterm 0.4.2.

TERM = rxvt

Don't know aterm, but putty needs to be configured to send a keep-alive package, if not, you'll be disconnected. Under recent putty.exe, it is under Connection. Maybe you need something like that.