New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You can make this yourself, but it might be a bit hard / annoying.
I know I can make my self, take a big ram vps server and make the ramdisk and load everything there, but if any stable, big uptime no crashes etc
put your money then, not on some $7 chicken
what are you trying to hide here? certainly not performance issue. if it's sensitive enough to be put in RAM, use your own hardware infrastructure. using vps services where the host can snoop your RAM make your setup a complete joke.
might get away with that on a dedi.
But most pure NVME PCI-EX GEN4 sorage with Ryzen CPU's will do perfect, above 4G/sec
You'd probably want a dedi in colo then. But yeah, ScreenReader says it pretty well.
Just get a VPS with a recent CPU, so you don't be stuck with low memory bw speeds.
Netcup maybe, had a recent EPYC launch, memory bandwidth when I tested was quite good.
What do you mean by ramdisk hosting?
If it's okay for the data to be on disk, write a script that copies your app into /dev/shm then runs it from there, and create a systemd unit to run the script. /dev/shm is a default ramdisk on Linux systems, or you can mount your own separate tmpfs.
If it's not okay for the data to be on disk (ie you want it only in RAM) then you'd likely have to use PXE (network booting) which is probably doable on a VPS, but might be a bit tricky to achieve.
OH, nothing to hide. I was curious if any, if I have something to hide I will do it in my own computer I have planty of ram, 128 gb ddr5 at 6ghz
Nothing special needed for this… vmtouch for reads and eatmydata for writes. Don’t bother with a VPS (except from one of the $$$ cloud providers) if your latency requirements are this low
Just mount a tmpfs (or simply use /tmp), put a diskimage of your favorite OS there and run Qemu with it's harddisk pointing to said image, voila, you have a VM fully in RAM. Obviously you could also configure a system to copy everything into a tmpfs on boot but that would be just pointlessly complicated for practically no upside.
Unless you're doing a lot of aggressive I/O writes on a bunch of tiny files, a RAM disk and an NVME are not likely to show any performance difference in the real world, other than a crash means your RAM disk VPS is completely gone.
You're not going to find a VPS but rather would need a minimum 32 GB RAM dedicated server to do what you want.
Hi,
there is no real usecase for this in general hosting ( afaik ). So you will not find (any?!) offers there.
Put your files in /dev/shm -- done.
also Linux kernel fscache is actually excellent.
Yea, until next reboot
My browser's default download directory is /dev/shm , but Chromium is pathetic in forbidding to upload anything from there.
Thx guys for answering, i was curious if any hosting do that in a smart way . But apparently thers a lot of alternatives to do it yourself not worth for some to do it really. Pcie Gen 5 nmve it's really fast these days.
What would be the smart way? What would that involve?
Nobody does this because it is way too easy to lose all the data.
Legit question, Why would you want RAM over NVMe ? (NVMe Gen. 4 & 5 are extremely fast)
RAM can be useful if you're doing something that does a lot of aggressive reads/writes and don't want to wear the underlying disk, or if a ton of extremely tiny files are being accessed repeatedly.
That said, I'm not sure if a whole VPS needs to be on RAM or if a RAM disk should be made within the VPS to run whatever aggressive I/O application is needed. (XY problem maybe?)
/tmpis not guaranteed to be in RAM - it could be a disk partition. This is why/dev/shmexists - it'll always be in RAM.In my opinion, ramdisks can be useful for certain tasks involving frequent ffast writes, but their use is somewhat limited due to the risk of data loss. Most linux boxes cache frequently accessed files from disk to RAM automatically, benefiting from faster reads without the risk of data loss.
I personally use a ramdisk partition on a dedicated box for building code, as it frequently pulls source code, creates and destroys thousands of files on the ramdisk during the build process, and then uploads the resulting build as a single package. Although this could happen on an NVMe with nearly the same write speed, I prefer not to wear down the flash memory cells with so much temporary files.
We have a little hyper visor monster spare... which we could transform to be your little Ram-Disk monster:
220€/month + vat
We will setup all the ram related stuff, you dont have to care about anything, we hand over you a VM with the given Ram-Disk (which just behaves as a local disk). Oh and dont forget, everything is lost in case of a power failure, even though its A/B, theres still a (little) chance..
Now show me your shiny use case for this
.
Good specs for the money, but for this spec it's nice to have SQL database to be quick 😜
SQL and quick never fits together
That's true but then i haven't seen a system that would mount physical storage on
/tmpin like forever (as far as i know guaranteed persistence across reboots is what sets/var/tmpapart from/tmpso unless there's some resource constraint hindering putting/tmpin RAM there's no point in backing/tmpwith physical storage) and if there's any doubts a quickmountwill clear them up. On most systems people are going to come across/tmpand/dev/shmwill be pretty much identical.Edit: Interesting... I've just checked a Debian system and my assumption seems to be wrong. There's nothing mounted on
/tmpat all. Not sure if that's some kind of custom config or if mounting tmpfs on/tmpactually isn't as common as i had thought. In any case physical backing for/tmpseems pretty pointless.plenty of distros doesnt mount tmpfs in /tmp, also it could be still that its swapped, which could end up on a physical disk instead of memory
..
to be really 100% percent running on memory, we suggest to use a kernel module to allocate the memory for the ram-disk