I recently had an issue with a Tomcat server taking very long to restart. It was bizarre because when the system was starting, the Tomcat server was taking about 20-30 seconds to start, but a subsequent Tomcat restart was taking 20-30 minutes.
The logs indicated that the following step was taking a lot of time:
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [135172] milliseconds.

This lead to the Tomcat page with advice on faster startup. The problem was – Tomcat was using /dev/random as source of randomness, and when the entropy pool was exhausted, this device was blocking.
This explained why the problem was not manifesting right after system restart: because of the associated ‘noise’, there was a lot of entropy. But after the system was stable, the entropy pool was depleted.

The solution to this is to tell Tomcat to use the non-blocking /dev/urandom device instead of /dev/random:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool.

A counterpart is /dev/urandom (“unlimited”) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random.
wikipedia

So, to make Tomcat use /dev/urandom you have 2 options:
1. As indicated in the Tomcat slow startup troubleshooting guide: Configure JRE to use a non-blocking entropy source by setting the following system property: Djava.security.egd=file:/dev/./urandom

2. Change the $JAVA_HOME/jre/lib/security/java.security settings file:
securerandom.source=file:/dev/urandom
instead of
securerandom.source=file:/dev/random

More about entropy

How do you measure it?
The current amount of entropy and the size of the Linux kernel entropy pool are available in /proc/sys/kernel/random/, which can be displayed by the command cat /proc/sys/kernel/random/entropy_avail. The maximum should be 4096 bytes.
Running watch -n 0.25 cat /proc/sys/kernel/random/entropy_avail will show how the entropy is used in real time.

Asking for bytes of entropy
100 bytes: head -c 100 /dev/random | xxd
Java SecureRandom doesn’t block?
If you want to generate a random string of 10 characters: #cat /dev/urandom| tr -dc 'a-zA-Z0-9' | fold -w 10| head -n 1

Wait for it…
If you want true random data, then unfortunately you have to wait for it.
How to solve performance problem with Java SecureRandom?

…or plug in an Entropy Key
The Entropy Key is a small, unobtrusive and easily installed USB stick that generates high-quality random numbers, or entropy, which can improve the performance, security and reliability of servers.
They show 2 examples of how quickly entropy is consumed: on a web/email server and on a personal computer immediately after the removal of the Entropy key:

Almost all the software running on this desktop will be using /dev/urandom, and the entropy pool shrinks to reflect this. However, as entropy is gathered from other sources (such as interrupts), the available entropy slowly increases over the period of 2 to 3 minutes, at which point it hits the watermark where it is acceptable for /dev/urandom to freshen itself with real entropy rather than rehashing old entropy, and it suddenly drops again, creating a saw-tooth pattern.

Why is this important?
Mostly for cryptographic operations: generating a random key is part of the HTTPS communication. Every time you visit a https web site, both your computer and the server must generate a random key.

From where do computers get entropy?
Disk reads, network activity, mouse movement, key presses, etc.

Modern computers and operating systems generate entropy based on events like electrical noise, timings of data coming into the computer over the network, what’s going on with the disks, etc. fed into algorithms — what we call pseudo-random number generators (PRNGs). A lot of data goes in and a relatively small amount of entropy comes out, but it’s entropy.

From where do computers should get entropy?
* Radioactive source: Hotbits
* Atmospheric noise from a radio: random.org
* Lava lamps
* Avalanche noise – like the Entropy Key

Conclusions
* dev/random is blocking and takes entropy from system activity (network, mouse, keyboard, etc)
* dev/urandom is non-blocking, but generates randomness programmatically
* entropy is important for the cryptography in general, HTTPS communication in particular
* external devices like Entropy Key can help improving the entropy
* computers are lousy random number generators

Read also this interesting story about Adventures in entropy.