Re: Putting $data_directory on a RAM filesystem
* Victor Duchovni victor.ducho...@morganstanley.com: On Sat, Jan 23, 2010 at 06:08:40PM +0100, Stefan Foerster wrote: In case of severe server overload, with postscreen(8) complaining about lookup and update times around 400ms almost every mail, is it (reasonably) safe as a last desperate measure to put $data_directory, or at least the file referenced by $postscreen_cache_map, on a ramdisk (e.g. tmpfs with Linux)? Yes, but I would still try to find out why the lookup times are so absurdly large? An exotic bug in the raid controller's firmware of the three servers slowed down access to certain parts of the raid array to the speed of molasses. It affected /var (and /boot), but not the LV which held $queue_directory. On the fourth, identical server, a slightly different disk layout was used for all testing and benchmarking. After verifying that the unattended installation worked, the three other servers were deployed into production with a larger LV for /usr. Upgrading the faulty firmware solved the problem. N.B: If you bother with testing at all, do it right. Stefan
Putting $data_directory on a RAM filesystem
In case of severe server overload, with postscreen(8) complaining about lookup and update times around 400ms almost every mail, is it (reasonably) safe as a last desperate measure to put $data_directory, or at least the file referenced by $postscreen_cache_map, on a ramdisk (e.g. tmpfs with Linux)? I know about RAM not being persistent across reboots, and I understand what happens if the $postscreen_cache_map (or all the contents in $data_directory) are lost. Stefan
Re: Putting $data_directory on a RAM filesystem
On Sat, Jan 23, 2010 at 06:08:40PM +0100, Stefan Foerster wrote: In case of severe server overload, with postscreen(8) complaining about lookup and update times around 400ms almost every mail, is it (reasonably) safe as a last desperate measure to put $data_directory, or at least the file referenced by $postscreen_cache_map, on a ramdisk (e.g. tmpfs with Linux)? Yes, but I would still try to find out why the lookup times are so absurdly large? -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Putting $data_directory on a RAM filesystem
Stefan Foerster: In case of severe server overload, with postscreen(8) complaining about lookup and update times around 400ms almost every mail, is it (reasonably) safe as a last desperate measure to put $data_directory, or at least the file referenced by $postscreen_cache_map, on a ramdisk (e.g. tmpfs with Linux)? Sure, but why do you expect that it will be FASTER? Are you perhaps running a busy mail server off a single disk drive? In that case, splitting the load over multiple drives would make a big difference. Is perhaps your system slow because of swapping? In that case, using tmpfs will make the system swap even more. Instead, even reducing the process count by 20% could result in a big over-all improvement. I haven't seen any attempt at a quantitative analysis of the problem, so I won't speculate further. Wietse
Re: Putting $data_directory on a RAM filesystem
Stefan Foerster put forth on 1/23/2010 11:08 AM: In case of severe server overload, with postscreen(8) complaining about lookup and update times around 400ms almost every mail, is it (reasonably) safe as a last desperate measure to put $data_directory, or at least the file referenced by $postscreen_cache_map, on a ramdisk (e.g. tmpfs with Linux)? I know about RAM not being persistent across reboots, and I understand what happens if the $postscreen_cache_map (or all the contents in $data_directory) are lost. If the problem is due to an I/O bottleneck, I'd recommend going SSD instead of RAM disk. Get this Crucial 64GB SATA2 unit and put both the postfix spool and postscreen db files on it: http://www.newegg.com/Product/Product.aspx?Item=N82E16820148318 Or, like Wietse said, first identify the actual cause of the problem. Then if it's I/O related, get an SSD drive. It's a relatively cheap path to massive random I/O throughput. -- Stan
