How to move /dev/random to another drive on a server

We found a bottleneck in our server (hosted on HDD) related to the /dev/random function. We want to have the OS use the /dev/random that is on our SSD drive rather than the HDD.

How can we have the server use /dev/random on another drive than the OS? would this be a Symbolic links or Hard links?

Any advice on how to accomplish this (use random from a different mounted server) would be appreciated.

Thanks!

edit Thanks to Scott for your patience :]

SOLR and OS runs on HDD. We have a SOLR index on an SSD volume. When we index files through java, that's running on the HDD and causing a lot of disc writes, so we want to move it over to the SSD (dictated not read).

d-_-b

Posted 2013-09-15T21:35:32.173

Reputation: 295

"We found that a java process is using lots of CPU on our HDD due to the random generator." this sentence does not make sense. You said the equivalent of "We found our car is using a lot of MPH in our gas tank while going on the highway". Please explain what you are measuring and how you measured it. – Scott Chamberlain – 2013-09-15T22:04:45.433

To address your last update: I don't see how running a file index has anything to do with /dev/random, please explain how you go from SOLR doing a file index causes lots of reads and writes on the drive to /dev/random is not generating bytes fast enough. – Scott Chamberlain – 2013-09-15T22:14:14.980

I agree scott. we don't really know what the problem is to ask the question correctly :/ I'll try to get more info and post a new question. thanks for your time – d-_-b – 2013-09-15T22:18:11.260

We're sending you to the parts counter to pick up a gallon of propwash, 300 feet of flight line and a set of piston return springs. Oh, and please move /dev/null to another hard drive when you get back. It's a snipe hunt. <grin> – Fiasco Labs – 2013-09-16T00:18:45.780

This doesn't appear to have anything to do with /dev/random. I suggest starting over with your question from the beginning, explaining the actual problem you are facing and any work you have already done toward solving it. – Michael Hampton – 2013-09-16T00:32:54.613

Answers

/dev/random is not a file that can be moved because it is not a "file" at all. /dev/ is actually a "empty" folder, the "files" inside it are put there by the kernel and exist only in memory. When you go to "read" or "write" to those files the kernel will intercept the call and it will never touch the hard drive at all.

This is a classic example of a XY Problem, please edit your question to include the details of what the bottleneck is and how you found it and we may be able to give you advice to the "Correct" way to fix that issue.

For example, if you do not need cryptographicly strong random numbers /dev/urandom is much, much faster but it is also more "predictable" than /dev/random (But not in a way that would matter to you, see the edit at the bottom). If you explain what you are using /dev/random we can help you decide if /dev/urandom would be a good choice or not.

Edit: Doing some more research, I have found that /dev/urandom should be fine to use for cryptographic uses too and will be much much faster.

Scott Chamberlain

Posted 2013-09-15T21:35:32.173

Reputation: 28 923

So long as the entropy pool has been seeded at startup (which every sane distribution does) /dev/urandom produces cryptographically strong random numbers. – David Schwartz – 2013-09-15T21:56:16.607

Thanks @Scott, that all makes sense. I guess we'd like a way to have our server do all read/write related to randomness through our SSD drive to take advantage of the faster processing. – d-_-b – 2013-09-15T21:59:09.687

@d-_-b you are missing the point, it does not use the drive at all right now!. So by somehow "forcing it to use the SSD" that will only make it orders of magnitude *slower*. – Scott Chamberlain – 2013-09-15T22:00:44.620

(btw I could not agree more with the XY Problem :) ) – d-_-b – 2013-09-15T22:04:44.957

In addition to @ScottChamberlain's answer, the device /dev/random serves as a random number generator. Every time you read from it, your computer tries to generate new random numbers. This requires CPU time. The bottleneck that you witness is most probably due to this fact. You cannot remove it unless you use a different (more light-weight) way of getting your random numbers.

nickie

Posted 2013-09-15T21:35:32.173

Reputation: 322

3It is not CPU time that it is waiting for, the big thing slowing /dev/random down is the fact that it will block and wait for the entropy pool to refill if it empties. – Scott Chamberlain – 2013-09-15T21:59:34.130

@ScottChamberlain, you're right of course. I just wanted to point out that even if you didn't require entropy-driven random numbers, you'd still face a bottleneck if you wanted too many of them. – nickie – 2013-09-15T22:02:35.573