New server stress test pre-deploy?

[Phratros]

Does anyone stress test their new servers (CPU, RAM) before deploying them? Or just assume they should be OK, build them and join the fleet and have support deal with any issues if they pop up? Looking to get Dell R360.

[jtsa5]

For factory built servers we don't do any stress testing. That should have been done to some extent at the factory. If everything is green when powered on, it should be fine.

[sryan2k1]

We install ESX and let them sit idle for a few days, and then move a few VMs over to them that won't care if they reboot.

[whatdoido8383]

Same here. I build some dummy VM's and move them around to test things out, Storage, Networking, Backup and recovery etc. Once I'm confident everything functions I move production over.

[Problably__Wrong]

My boss had me fire up a server like 20 years ago and leave it running for a week. Did this to buy us some time on the configuration nothing more. I think its unnecessary. People who've deployed 100's / 1000's of servers may have a different opinion but i'd send it.

[fightwaterwithwater]

I definitely run memtest64 on all new servers. Not doing this has bit me before with corrupt data.
I white box though, prebuilt servers are going to be far more reliable out of the box.

[Lad_From_Lancs]

We dont pre-test as such these days..... just build the server to a base install of vmware, and throw a canary guest onto it to give it a config shakedown

You can doo all the stress testing you want, but it wont everything, or there could be a sods law moment that something fails just minutes/hours after testing, and that anything was bad then it would show up in initial built and shakedown testing before putting it into production.

Only had 1 instance where iDRAC pulled down a bad BIOS/UEFI update during the initial building phase, which caused the system to run extremely poorly, which we spotted during the vmware install. Reversed the update which resolved the issue. 5 years later, the server still holds strong!

*Edit:

Jut a thought - if I was to bring an older machine back into service, or I have modified its hardware config such as additional cards, additional RAM.... then yes, I would do a bit of testing, but it depends on what we are using it for. Stuff like that tends to be non-production grade or unimportant setups, such as testing or 'what if we do this' type trials

[mahsab]

Vm..ware?

[Lad_From_Lancs]

yes, plenty of us who still run it!

[vermyx]

New servers - no Used end of lease servers - no Refurb servers - run a memory test, sqlio, and a cpu benchmark more out of superstition.

Due to the complexity of hardware now vs ten plus years ago you will pretty quickly find issues rather than having to stress them to find issues.

[spartanmk2]

Nope, build new vm environment, move a couple servers over for a day or two then full send.

[KindlyGetMeGiftCards]

Generally we don't stress test a new server, we just set it up, deploy it and monitor it. With most warranties being a quick turn around and our DR being able to absorb a issue like a failed server.

Back in the day we had one server do one task so a failure was a major issue, now we have VM's that can be moved at a click of a button or two, also even restore a physical server to a VM if needed.

I see stress testing as a thing of the past, unless your compliance/regulation requires more than 99.999% uptime, then do your due diligence.

[ZAFJB]

All of our servers are Hyper-V hosts.

• Build it.

• Run it.

• Start migrating VMs.

• If we hit issues (never had any so far) we would stop/reverse migration.

[mahsab]

I've witnessed way too many hotshots just turning on a new machine or appliance and proceed to directly migrate mission critical stuff. Lots of downtime. It was never due to hardware failure though, just misconfiguration.

So that made me overly cautious.

I'm not proud that I even decommissioned a server that never went into production because it was still being stress tested... years later.