0

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).

Improve this question
5
  • "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
    Sep 15, 2013 at 22:04
  • 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
    Sep 15, 2013 at 22:14
  • 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
    Sep 15, 2013 at 22:18
  • 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
    Sep 16, 2013 at 0:18
  • 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
    Sep 16, 2013 at 0:32

2 Answers 2

Reset to default
6

/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.

Improve this answer
4
  • 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
    Sep 15, 2013 at 21:56
  • 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
    Sep 15, 2013 at 21:59
  • @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
    Sep 15, 2013 at 22:00
  • (btw I could not agree more with the XY Problem :) )
    – d-_-b
    Sep 15, 2013 at 22:04
2

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.

Improve this answer
2
  • 3
    It 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
    Sep 15, 2013 at 21:59
  • @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
    Sep 15, 2013 at 22:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .