This content originally appeared on DEV Community and was authored by Shawn Holland
Remember... I DO NOT KNOW WHAT I AM DOING.
Continuing from the last article, let's talk about the hardware failures and server upgrade.
- Mouse Input Support
- Hardware Failure
- Server Upgrade
- UEFI vs OpenSuSE Installer
- 32bit -> 64bit & Perl's Storable
All your bad sectors are belong to us.....
Ugh, seeing these sort of log errors screams panic to me
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], Self-Test Log error count increased from 3 to 4
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], previous self-test completed with error (read test element)
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 184 End-to-End_Error.
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], 136 Offline uncorrectable sectors
Nov 25 03:44:25 Dev smartd[627]: Device: /dev/sda [SAT], 136 Currently unreadable (pending) sectors
My Dev/Test server's hard drive is going bad and I need to deal with this ASAP! It's one of those all in one PC's Acer makes You can see it far right, tucked behind the laptops in this pic of my setup.
It's been a while since I've had to look at system logs in Linux OpenSuSE. I used to remember just doing a tail -f /var/log/messages or what ever log file you wanted to watch. I guess at some point since then they switched to using systemd journal service and you can now view everything using journalctl
We can rebuild it, we have the technology...
This is actually OK. I back up my code, so I'm not worried about data loss. Aaaaand... I just so happen to have another Acer computer that has been sitting in a cardboard box in pieces for a long time. Buuut... this other computer is much better spec'd.
Here you can see a neofetch comparison of the 2 servers side by side. Left is the "new" server, right is the old server with the bad HDD.
Notable upgrades:
- 32bit -> 64bit Architecture
- 2 Core -> 4 Core CPU
- 4 GB -> 6 GB RAM
- A Very Slow 1 TB -> Much Faster 1.5 TB HDD
I'm excited mainly for the extra core count for forking and the working hard drive, that is exceptionally faster.
Running an fio test shows dramatic differences in results.
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=4 --runtime=240 --group_reporting
Old server write speeds are around 6789kB/s and took a few minutes to run. The new server performs @ 109MB/s and finished the test in a few seconds. I'd say we should see a huge performance increase, and we do!
The engine can do a lot of writing to the hard drive at times, and I used to see the lag, now... no lag from the hard drive! Nice and quick! Also no bad sectors.
I've read somewhere that you may not want to perform randwrite against a device that is in use... So, be careful. I did it with no apparent problems, and the bad sectors were well before ever running the fio command.
Let me know if you have any experience with hard drive failure diagnosing and testing write speeds with fio.
If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.
ANSI Game Engine on Instagram
ANSI Game Engine on Facebook
Prev << Part 2 - Mouse Input
Next >> Part 4 - UEFI vs OpenSuSE Installer
Cheers!
Shawn
This content originally appeared on DEV Community and was authored by Shawn Holland
Shawn Holland | Sciencx (2021-12-01T01:03:41+00:00) Developing A Game Engine with Perl: Part 3 – Hardware Failure & Server Upgrade. Retrieved from https://www.scien.cx/2021/12/01/developing-a-game-engine-with-perl-part-3-hardware-failure-server-upgrade/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.