I have a script that creates large temporary files.
I'm inclined to use tmpfs for this, however I did a quick search for tmpfs performance and found this which reports speed as about 2GiB/s.
Modern NVME SSDs have comparable speeds. Putting aside differences other than performance (e.g. longer SSD life by not touching disk, SSDs having a larger while RAM is limited), are there any performance advantages of using tmpfs over SSDs?
I'm looking for info about mounting a tmpfs partition and sync option. Sync makes the data beeing dumped onto the disk without beeing saved in cache. This works with ext4 and other filesystems. I'm wondering is even a tmpfs partition needs the sync option to be specified or it is enabled by default since it is a RAM partition. In my option it would be odd if a ramdisk would be cached in RAM.
tmpfs /tmp tmpfs defaults,sync,noatime,nosuid,nodev,noexec,mode=0777,size=400M 0 0
In a tmpfs partition is sync enabled by default?
Since a tmpfs exists only in memory, can it become fragmented like memory can? Are there mechanisms to automatically defragment the memory, and thus increase - even slightly - the access speed of stored files?
/var/log/lastlog gets written to when you log in. The size of this file is based off of the largest UID in the system. The larger the maximum UID, the larger this file is. Thankfully it's a sparse file so the size on disk is much smaller than the size ls reports (ls -s reports the size on disk).
On our system we're authenticating against an Active Directory server, and the UIDs users are assigned end up being really, really large. Like, say, UID 900,000,000 for the first AD user, 900,000,001 for the second, etc.
That's strange but should be okay. It results in /var/log/lastlog being huuuuuge, though--once an AD user logs in lastlog shows up as 280GB. Its real size is still small, thankfully.
This works fine when /var/log/lastlog is stored on the hard drive on an ext3 filesystem. It breaks, however, if lastlog is stored in a tmpfs filesystem. Then it appears that the max file size for any file on the tmpfs is 256GB, so the sessreg program errors out trying to write to lastlog.
Where is this 256GB limit coming from, and how can I increase it?
As a simple test for creating large sparse files I've been doing:
dd if=/dev/zero of=sparse-file bs=1 count=1 seek=300GB
I've tried Googling for "tmpfs max file size", "256GB filesystem limit", "linux max file size", things like that. I haven't been able to find much. The only mention of 256GB I can find is that ext3 filesystems with 2KB blocks are limited to 256GB files. But our hard drives are formatted with 4K blocks so that doesn't seem to be it--not to mention this is happening in a tmpfs mounted ON TOP of the hard drive so the ext3 partition shouldn't be a factor.
This is all happening on a 64-bit Red Hat Enterprise Linux 5.4 system. Interestingly, on my personal development machine, which is a 32-bit Fedora Core 6 box, I can create 300GB+ files in tmpfs filesystems no problem. On the RHEL5.4 systems it is no go.
I have heavy application running on a CentOS server and I'm seeing a strange memory behavior. Here is a snapshot of a munin graph:
As you can see the amount of committed memory increases gradually causing the swap file to be use. What strikes me odd is that the amount of inactive memory keeps growing as well. It is my understanding that the inactive memory is actually memory freed up but not yet clean by the OS and put back in the free memory pool. It seems that running out of memory is acutally caused by this lack of clean up, but I may be wrong.
Can you give some tips to find the cause of the problem and/or cause CentOS to reclaim the inactive memory?
Thanks.
Some extra info:
1) I have a tmpfs mounted on /tmp and the number of files stored there grows (but it is double the amount of the inactive memory).
2) cat /proc/meminfo (at a later stage than the image) gives:
MemTotal: 14371428 kB
MemFree: 1207108 kB
Buffers: 35440 kB
Cached: 4276628 kB
SwapCached: 785316 kB
Active: 9038924 kB
Inactive: 3902876 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 14371428 kB
LowFree: 1207108 kB
SwapTotal: 10223608 kB
SwapFree: 6438320 kB
Dirty: 627792 kB
Writeback: 0 kB
AnonPages: 7844560 kB
Mapped: 49304 kB
Slab: 146676 kB
PageTables: 27480 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 17409320 kB
Committed_AS: 16471488 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 275852 kB
VmallocChunk: 34359462007 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
3) The application is a combination of MySQL, Heritrix (http://crawler.archive.org/ ) and a Tomcat based Java servlet to manage things.