Traditionally, cat /dev/urandom | tr -dc 'a-zA-Z0-9' can cause 100% CPU spikes on low-end servers due to a 76% byte rejection rate. By switching to openssl rand -base64, I reduced the rejection rate to <3%, preventing system freezes for thousands of users on budget VPS instances.

The Invisible Bottleneck

Imagine you are a student or a hobbyist on a tight budget (like myself). You’ve just rented a $7.5/month virtual private server (VPS) with a single core and 512MB of RAM. You connect to it, paste the installation command for 3X-UI—a massively popular open-source networking panel with over 315,000 stars on GitHub—and hit Enter.

Instead of a success message, your SSH terminal freezes. The server becomes completely unresponsive. You’ve lost control of your instance without any warning.

That’s exactly what I encountered after solving a DDoS problem on my Hong Kong instance. I was looking for ways to keep it online during flood attacks, as my service provider would cut off international routes after monitoring such attacks. It turned out that only the Internet Exchange (IX) remained accessible after a “lockdown.” Luckily, Google Cloud Platform (GCP) offers small 1 vCPU + 614 MB RAM Linux instances for a relatively low budget of $7.5 USD per month. My plan was to route requests from my Hong Kong VM through this instance to provide better connectivity.

The idea was solid, but it was almost ruined by the limitations of the GCP instance.

The 75% Death Loop

I noticed that the 3X-UI installation script took an unusually long time to execute on my GCP instance. After checking the system load, I identified the abnormality: a single process named tr was consuming 100% of the CPU and had been running for over 6 seconds.

Due to poor performance on GCP’s e2-micro instance, running the original tr command would cause the system to hang entirely — making benchmarking impossible. The screenshot below captures the moment tr consumed 100% CPU during installation.

CPU usage screenshot

Tracing the installation script led me to the culprit: a seemingly harmless bash function called gen_random_string. To generate default passwords and routing paths, the script used this command:

cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 10 | head -n 1

At first glance, it looks standard. It pulls random bytes, filters for alphanumeric characters, and grabs the first 10. But mathematically, it’s a disaster for low-end CPUs.

The /dev/urandom generator outputs bytes ranging from 0 to 255 (256 possibilities). However, we only want letters and numbers (62 possibilities). This means the tr command rejects about 76% of all generated bytes. The CPU is forced into a highly inefficient loop, generating and immediately discarding data until it finally collects enough valid characters.

On a modern MacBook, this takes milliseconds. But on a hyper-restricted virtual machine like Google Cloud’s e2-micro, it triggers a 100% CPU spike, draining all CPU burst credits in seconds and causing the system to hang.

An Elegant, Cryptographic Solution

To fix this, we needed a method with a drastically lower rejection rate. I rewrote the function using OpenSSL:

openssl rand -base64 15 | tr -dc 'a-zA-Z0-9' | head -c 10

Why is this better?

Base64 encoding consists of 64 characters (A-Z, a-z, 0-9, +, /). By generating a Base64 string first, our target characters now make up 62 out of 64 possibilities. The byte rejection rate plummets from 76% to less than 3%. The CPU spike disappeared entirely.

Furthermore, openssl rand uses a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), making the generated passwords cryptographically secure*. Also it has more predicatable outcome across different Linux distributions.

The Real Challenge: Defending the Code

I submitted my Pull Request (PR), expecting a quick merge. Instead, a senior contributor commented: “Maybe it’s worth using a simpler and lighter program - pwgen?”

This was a critical moment. I could have blindly agreed or stubbornly argued. Instead, I analyzed the software architecture as a whole.

I explained that while pwgen is small, it is not universally available. On minimal Linux distributions like Alpine, installing pwgen requires adding third-party repositories—a significant hurdle for an automated script. More importantly, the installation script already relies on curl to download files, and curl implicitly depends on OpenSSL.

OpenSSL wasn’t an “extra dependency”; it was an existing, ubiquitous core utility waiting to be utilized.

I replied politely, explaining the architectural trade-offs: cross-distribution compatibility, the implicit curl dependency, and the cryptographic security of CSPRNG. The reviewer was satisfied, and the core maintainer not only approved my logic but asked me to apply the patch to all other scripts in the repository.

And that is how I got my first PR merged! 🌟

In the End:

By fixing this 6-line function, I wasn’t just optimizing a script; I was lowering the barrier for the entire 3x-ui community.

For many users running on low budget “potato” VPSs, this change meant the difference between a successful deployment and a frustrated system reboot. We turned a 6-second CPU-melting process (Or even led to force-reboot scenario) into a near-instantaneous operation, significantly saving installation time and reducing technical hurdles. In the world of open source, sometimes the smallest technical tweaks provide the most significant accessibility wins for users worldwide.

Links & References

*openssl rand uses a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) — meaning the generated values are computationally infeasible to predict, even if an attacker knows previous outputs.