Everyone, I am putting together a new mail server for our firm using a SuperMicro with Centos 7.0. When performed the install of the os, I put 16 gigs of memory in the wrong slots on the mother board which caused the SuperMicro to recognize 8 gigs instead of 16 gigs. When I installed Centos 7.0, this error made the swap file 8070 megs instead of what I would have expected to be a over 16000 megs. I am using the default xfs file system on the other partitions. Is there a way to expand the swap file? If not, then is this problem sufficiently bad enough for me to start over with a new install. I do not want to start over unless I need to. Thanks for you help !!! Greg Ennis
Hey Gregory, I assume you have the issue with a swap partition which is harder to modify then a swap file. You can always add\use another swap file instead of a partition. This article describes what you will need\want: cyberciti.biz/faq/linux-add-a-swap-file-howto and just another one for more info: rackspace.com/knowledge_center/article/create-a-linux-swap-file Eliezer On 15/02/2015 19:42, Gregory P. Ennis wrote:> I am using the default xfs file system on the other partitions. Is > there a way to expand the swap file? If not, then is this problem > sufficiently bad enough for me to start over with a new install. I do > not want to start over unless I need to. > > Thanks for you help !!! > > Greg Ennis
I'd like to think you will want to avoid the use of swap at almost all costs because it'll slow the system down by a lot. So really you don't need 1:1 for a server that isn't using suspend to disk. You only need enough swap so that things can chug (slowly) without totally imploding, giving you enough time to kill whatever is hogging RAM or do a more graceful reboot than you otherwise would. It's fairly stable now, but the longer term solution for this is LVM thin provisioning will mean a bulk of extents will remain free (not associated with any LV) until they're needed. While you wouldn't use a thin volume for swap, but free extents can be used to make the conventional LV used for swap bigger. And for thin volumes it can mostly obviate even having to resize them.
Morning Gregory, Sunday, February 15, 2015, 6:42:32 PM, you wrote:> I am putting together a new mail server for [...] > I am using the default xfs file system on the other partitions. Is > there a way to expand the swap file? If not, then is this problem > sufficiently bad enough for me to start over with a new install. I do > not want to start over unless I need to.I think that on todays system, swap is just "the last resort" before a system crashes. If you ever run into the situation that you need the swap system, you will have to throw more memory into the machine. I wouldn't care. Btw., are you sure you want to use XFS for a mail server? I made some tests about a year ago and found that EXT4 is by the factor 10 faster compared to XFS. The tests I performed were using the "maildir" style postfix installation that results in many thousands files in the user directories. The only problem was that Centos was not able to format huge ext4 partitions out of the box. This was valid for C6, don't know about C7. best regards --- Michael Schumacher
On Mon, Feb 16, 2015 at 12:07 AM, Michael Schumacher <michael.schumacher at pamas.de> wrote:> Btw., are you sure you want to use XFS for a mail server? I made some > tests about a year ago and found that EXT4 is by the factor 10 faster > compared to XFS. The tests I performed were using the "maildir" style > postfix installation that results in many thousands files in the user > directories.This is a recent benchmarking using Postmark which supposedly simulates mail servers. XFS stacks up a bit better than ext4. phoronix.com/scan.php?page=article&item=linux-3.19-ssd-fs&num=3 A neat trick for big busy mail servers that comes up on linux-raid@ and the XFS list from time to time, is using md linear/concat to put together the physical drives into a single logical block device, and then format it XFS. XFS will create multiple AG's across all of those devices, and do parallel writes across all of them. It's often quite a bit better performing than raid0 specifically because of the many thousands of small files in many directories workload. -- Chris Murphy