Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Enzo]

All morning, it was "timing out" when I tried to post...

Yeah, I was having this problem before I went to work. I was also getting nginx errors most of yesterday. Seems to be fine now though.

[Shades]

Regardless, hosts with overrestricted VPS settings are one of a number of reasons why I avoid VPSes like the plague.

Why don't you just avoid the over restrictive ones instead. A (decent) VPS has much to offer over a 'dedicated host', in fact I often recommend anyone actually running sites hosted on physical systems to get hold of something like XEN and turn all their hosts into virtual ones.

The current level of hardware tech means you have almost zero overhead and the benefits of being able to move and scale hosts quickly is something that can't be overlooked. It's much easier to restart a crashed VPS than hardware in some server farm too. Much cheaper too as you tend to waste far fewer cycles because you can scale so fast.

I should point out I only use self managed VPSs, so I've not really come across limits like that, but then I have control freak like issues.

[Blacken]

Shades is right, IMO--dealing with hardware yourself really kind of sucks. A decent VPS provider (I use Slicehost or Rackspace Cloud, which is in itself a reseller for Slicehost, for basically everything) allows you to be far, far more flexible, and generally for less money.

[qwertyuiopas]

Well, if the problem is(and it likely is) the number of connections, then the issue is that while downloading DF or DFtalk, that your connection is going to be open far longer than just browsing the forum.

Naturally, what happens, is even if only 1 in 5 connects succeed, the downloaders will have a connection open the whole time they are downloading, while forum users will close their connections as soon as they have the relatively small page downloaded.

Because of that, the available connections would fill up quickly, since most take at least 10 seconds to finish, though probably far longer, depending on the size of the file. DFtalk was a large file, so even though there wasn't as great of a rush to get it, each connection would stay open longer, so fewer forum users could get through because more of the downloads would be active at once.

Most of this is speculation, but the fact that the downloads take time to get while forum pages are relatively small, and the discusses probability of limited connections, can be easily put together to get this.

[Locriani]

And that's a restriction of non-xen virtualized hosts.  Xen is a hypervisor (paravirtualization) while Virtuozzo is an operating system level container.  Since Xen has finer control over resources, it can actually allocate them fairly without arbitrary limits on shmpages or maxtcpconn or etc.  A dedicated server is usually not worth the cash; even if it is, though, you should be sticking Xen on it to compartmentalize your resources.

Linode comes with my recommendation; as I run the dfwiki on 3 linodes as well as the rest of my company's applications on 30 other linodes, of various sizes.  Since Linode uses Xen, there are no arbitrary resource limitations except for those in the contract (memory amount, hard disk space, CPU share if and only if the host is under heavy load).

[Blacken]

Well, if the problem is(and it likely is) the number of connections, then the issue is that while downloading DF or DFtalk, that your connection is going to be open far longer than just browsing the forum.

Naturally, what happens, is even if only 1 in 5 connects succeed, the downloaders will have a connection open the whole time they are downloading, while forum users will close their connections as soon as they have the relatively small page downloaded.

Because of that, the available connections would fill up quickly, since most take at least 10 seconds to finish, though probably far longer, depending on the size of the file. DFtalk was a large file, so even though there wasn't as great of a rush to get it, each connection would stay open longer, so fewer forum users could get through because more of the downloads would be active at once.

Most of this is speculation, but the fact that the downloads take time to get while forum pages are relatively small, and the discusses probability of limited connections, can be easily put together to get this.

The danger of you writing with such an authoritative tone is that people might think that you know what you're talking about and taking your comments as something to be relied on as factual. In truth, what you have said has no bearing on reality. There is no "available connections" limit (except for a very obscure one in code, based on the limit of file descriptors on the system--usually no less than 100,000, often many more). Each takes up a trivial amount of memory (on the order of kilobytes) and it's not like there is a bandwidth/throughput issue that large files exacerbate--the point of a modern TCP stack is to allow an arbitrary number of connections and ensure that (sans QoS, which changes the rules) each receives approximately proportional bandwidth.

The problem is a configuration issue with shared application containers; I've seen it before on improperly configured Virtuozzo setups (and I can attest that Lunarpages doesn't configure anything correctly, they're among the worst hosts I've ever been forced to use). It would happen without regard to the type of connections.

[Urist McDepravity]

There is no "available connections" limit (except for a very obscure one in code, based on the limit of file descriptors on the system--usually no less than 100,000, often many more). Each takes up a trivial amount of memory (on the order of kilobytes) and it's not like there is a bandwidth/throughput issue that large files exacerbate--the point of a modern TCP stack is to allow an arbitrary number of connections and ensure that (sans QoS, which changes the rules) each receives approximately proportional bandwidth.

You should look up Virtuozzo docs and see yourself that there IS tcp connections limit. Plus each connection takes a file handler, which is also quite limited on typical virtuozzo's.
You should not flame on people before checking your facts.

Heres typical virtuozzo limits (keyweb's VPS):

Spoiler (click to show/hide)

            numtcpsock           68         68        360        360          0
            numflock              7          7        188        206          0
            numpty                3          3         16         16          0
            numsiginfo            0          0        256        256          0
            tcpsndbuf        217624     219860    1720320    2703360       7841
            tcprcvbuf        214916     216128    1720320    2703360         28
            othersockbuf      29904      30604    1126080    2097152          0
            dgramrcvbuf           0          0     262144     262144          0
            numothersock         37         38        360        360          0
            dcachesize            0          0    2273280    2416640          0
            numfile            3151       3201       5820       5820          0

Where numtcpsock limits number of open connections.

[Shades]

Does this site use virtuozzo? Most VPS hosts I've seen (and all the ones I've worked with) use Xen.

[Baughn]

It does. Don't worry, we'll be moving from lunarpages Soon(tm).

[Blacken]

You should look up Virtuozzo docs and see yourself that there IS tcp connections limit.

I've run Virtuozzo servers. Even on Virt best practice is to set numtcpsock to unlimited, because too many applications expect unlimited access (and in practice it's not really that big a deal). Did "the problem is a configuration issue with shared application containers" escape you?

[Urist McDepravity]

SYSTEM WARNING: session_start() [function.session-start]: open(/tmp/sess_rcr***, O_RDWR) failed: Disk quota exceeded (122)

[qwertyuiopas]

- The server has a limited number of allowed network connections. If we get a backlog, it's likely to overrun that.

The source quote that I didn't feel I needed at the time.
TL;DR Vs. Read the Thread?

[Xeriar]

Why don't you just avoid the over restrictive ones instead. A (decent) VPS has much to offer over a 'dedicated host', in fact I often recommend anyone actually running sites hosted on physical systems to get hold of something like XEN and turn all their hosts into virtual ones.

I have completely and utterly destroyed several : )

Granted, that was with virtuozzo, but I outgrew a VPS for my main site a long time ago. I do want to pick apart Xen at some point, will see.

The current level of hardware tech means you have almost zero overhead and the benefits of being able to move and scale hosts quickly is something that can't be overlooked. It's much easier to restart a crashed VPS than hardware in some server farm too. Much cheaper too as you tend to waste far fewer cycles because you can scale so fast.

I should point out I only use self managed VPSs, so I've not really come across limits like that, but then I have control freak like issues.

Has there been any update on the ring0 vulnerabilities here? I wouldn't mind chopping up a machine with Xen but I'm still a bit leery when it comes to security.

I've run Virtuozzo servers. Even on Virt best practice is to set numtcpsock to unlimited, because too many applications expect unlimited access (and in practice it's not really that big a deal). Did "the problem is a configuration issue with shared application containers" escape you?

Shouldn't even be using tcp for fastcgi on the same machine in the first place, honestly.

Heres typical virtuozzo limits (keyweb's VPS):

Spoiler (click to show/hide)

            numtcpsock           68         68        360        360          0
            numflock              7          7        188        206          0
            numpty                3          3         16         16          0
            numsiginfo            0          0        256        256          0
            tcpsndbuf        217624     219860    1720320    2703360       7841
            tcprcvbuf        214916     216128    1720320    2703360         28
            othersockbuf      29904      30604    1126080    2097152          0
            dgramrcvbuf           0          0     262144     262144          0
            numothersock         37         38        360        360          0
            dcachesize            0          0    2273280    2416640          0
            numfile            3151       3201       5820       5820          0

Where numtcpsock limits number of open connections.

Those are not typical. Most hosts learn fairly early on in their adventures with VPS that these limits usually just get in the way.

Here's one from my host (still haven't replaced this one):

Spoiler (click to show/hide)

cat /proc/user_beancounters
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
     6362:  kmemsize                 23004248             23026541  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                    0  9223372036854775807  9223372036854775807                    0
            privvmpages                549836               550286  9223372036854775807  9223372036854775807                    0
            shmpages                    65138                65138  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                       235                  235  9223372036854775807  9223372036854775807                    0
            physpages                  136478               136478  9223372036854775807  9223372036854775807                    0
            vmguarpages                     0                    0  9223372036854775807  9223372036854775807                    0
            oomguarpages               159700               159700  9223372036854775807  9223372036854775807                    0
            numtcpsock                     41                   41  9223372036854775807  9223372036854775807                    0
            numflock                      138                  139  9223372036854775807  9223372036854775807                    0
            numpty                          1                    1  9223372036854775807  9223372036854775807                    0
            numsiginfo                     48                   49  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                 2294208              2294208  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                  671744               589824  9223372036854775807  9223372036854775807                    0
            othersockbuf                85056               128192  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                    0  9223372036854775807  9223372036854775807                    0
            numothersock                   57                   65  9223372036854775807  9223372036854775807                    0
            dcachesize                4969188              5003931  9223372036854775807  9223372036854775807                    0
            numfile                      9572                 9572  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      53                   53  9223372036854775807  9223372036854775807                    0

Edit: While most of these are 'unlimited', the host instead has monitors that trip things if someone's running a fork bomb, etc.