Matt Dillon
Retardium User
Another forum was having the same problem.
Gonna keep my mouth shut about Cloudflare lest I get some "How many traffic lights?" bullshit.
Site is slow AF 17 members, 12K crawler bots.
- Thread starter Matt Dillon
- Start date
Gonna keep my mouth shut about Cloudflare lest I get some "How many traffic lights?" bullshit.
It's a VM - shouldn't need reboots.
I dunno. But it's faster today. Maybe just for awhile??
Matt Dillon
Retardium User
Seems better right now. The twattiness of QP posts doesn't, but they're loading!
Into the Night
Contributor
DOS attack again.
Total: 14,539 (members: 13, guests: 14,526).
Gotta find out how these bots are getting through.
Total: 14,539 (members: 13, guests: 14,526).
Gotta find out how these bots are getting through.
IBDaMann
Probably the worse human in the threads
There are only three possibilities:
1. The most likely scenario, they are all just lurking here to read my posts
2. They are Robert Northup's army of biogeochemist disciples, cluelessly searching for his "library" on the wrong site
3. JPP is in for an imminent deluge of new members and the Introductions, User Announcements, Suggestions and forum should get ready for above-average bandwidth consumption.
The left does NOT like what we have to say on this site.
Into the Night
Contributor
A VM can be rebooted.
Of course. But isn't generally susceptible to memory leaks and other conditions the commonly cause regular reboots.
Into the Night
Contributor
The last I worked with was Morpheus. The pooled memory allocation self-corrected common memory leak issues. Since allocation is virtual and not physical, failure to release memory is addressed at the hypervisor level. This won't correct 100% of memory leak issues, but will correct a good 90%. Lockheed ran MasterCam - the king of memory leaks and Morpheus managed pooling well enough that nightly reboots were no longer needed on the engineering servers as they were with physical boxes.
But the most common issue that required a reboot was network related, NIC chatter, 16X bonding of gigabit cards could often end up in collision storms with the switch, especially is someone did what they loved to do in El Segundo and tossed in a SOHO unmanaged, the little blue Linksys rodents that would infest departments.
Further, enterprise level hypervisors, VMWare ESXi or HP Morpheus are clustered. If a host is acting up, fail over rather than incur downtime. Cloud farms use massive scale clustering to maximize uptime. The need to reboot a VM based server should be as rare as seeing bigfoot.
Addressed above.
Into the Night
Contributor
...so?
There is no 'pooled memory allocation' of a VM. A VM does not 'self correct' anything.
Allocation of memory for a VM is physical memory. How the VM handles that memory is up to the VM.
False equivalence.
Argument from randU fallacy. Memory is not 'corrected' by a VM. Any process running in a VM can leak memory just like a base process can.
Any VM process can leak memory just like a base process can. Rebooting a VM is just as necessary as rebooting a machine.
Linksys is not a rodent.
VMs do not have hard NICs.
There is no such thing as a 'collision storm with a switch'.
There is no such thing as an 'enterprise level hypervisor'.
Failover means abandoning one of the VMs because it crashed. Usually the VM is automatically rebooted and returns to the pool upon recovery.
'scale clustering' is a buzzword.
Servers for cloud services (including such cloud services as AWS, Azure, and Google) are built to scale, yes.
They are also built to 'cluster', or have established pools of VMs they can turn to as needed to run tasks in parallel, and to cover failure of a VM.
A VM still suffers all the problems a base machine does. They are rebooted all the time due to memory leaks, crashed process detection, or simply adding to the cluster pool.
It sounds like you are believing the marketing hype but not the actual method of how this stuff is implemented.
It is the holographic nature of the way VMs are allocated to conduct cloud services that makes them so reliable and scalable. An individual VM can crash, and it doesn't really affect the cloud service at all. Whole server farms can physically be destroyed and the service keeps on running in another server farm.
VMs can be programmed to automatically reboot when they crash, essentially emulating the 'power restored' feature of a BIOS.
Matt Dillon
Retardium User
It's much mo' bettah now! 
Into the Night
Contributor
Current load: Total: 7,511 (members: 15, guests: 7,496)
Site seems to be responding slightly slow, but manageable.
Earlier there were 17,000 bots, and site took 5 minutes to load a single screen.
Apparently loading seems to work up to about eight to nine thousand bots hitting the site. At about 12000 bots it becomes nasty slow, at 17000 bots, it's effectively offline.
Until something is done about blocking these bots, the site will continue to suffer inconsistent availability. Higher bot load seems to be mostly in the evening and overnight hours.
Site seems to be responding slightly slow, but manageable.
Earlier there were 17,000 bots, and site took 5 minutes to load a single screen.
Apparently loading seems to work up to about eight to nine thousand bots hitting the site. At about 12000 bots it becomes nasty slow, at 17000 bots, it's effectively offline.
Until something is done about blocking these bots, the site will continue to suffer inconsistent availability. Higher bot load seems to be mostly in the evening and overnight hours.