On 10/10/2011 8:51 AM, Wietse Venema wrote:
> Stan Hoeppner:
>> I'll work on getting access to suitable hardware so I can publish some
>> thorough first hand head-to-head numbers, hopefully with a test harness
>> that will use Postfix/SMTP and Dovecot/IMAP instead of a purely
>> synthetic benchmark
Stan Hoeppner:
> I'll work on getting access to suitable hardware so I can publish some
> thorough first hand head-to-head numbers, hopefully with a test harness
> that will use Postfix/SMTP and Dovecot/IMAP instead of a purely
> synthetic benchmark.
Until you have first-hand experience, perhaps y
Bron Gondwana:
> On Sun, Oct 09, 2011 at 04:42:25PM -0400, vg_ us wrote:
> > will postmark transaction test do? here -
> > http://www.phoronix.com/scan.php?page=article&item=linux_2639_fs&num=1
>
> Oh:
>
> http://blog.goolamabbas.org/2007/06/17/postmark-is-not-a-mail-server-benchmark/
>
> "Th
On 10/9/2011 3:42 PM, vg_ us wrote:
> will postmark transaction test do? here -
> http://www.phoronix.com/scan.php?page=article&item=linux_2639_fs&num=1
> stop arguing - I think postmark transaction was the only relevant test
> XFS was loosing badly - not anymore...
> search www.phoronix.com for o
On 10/9/2011 6:27 PM, Bron Gondwana wrote:
> On Sun, Oct 09, 2011 at 06:03:36PM -0500, Stan Hoeppner wrote:
>> XFS has been seeing substantial development for a few years now due to
>> interest from RedHat, who plan to make it the default RHEL filesystem in
>> the future. They've dedicated seriou
On 10/9/2011 4:49 PM, karave...@mail.bg wrote:
> I run a couple of busy postfix MX servers with queues now on XFS:
> average: 400 deliveries per minute
> peak: 1200 deliveries per minute.
>
> 4 months ago they were hosted on 8 core Xeon, 6xSAS10k RAID 10
> machines. The spools were on ext4.
>
On Sun, Oct 09, 2011 at 06:03:36PM -0500, Stan Hoeppner wrote:
> On 10/9/2011 3:29 PM, Bron Gondwana wrote:
>
> > I'm honestly more interested in maildir type workload too, spool doesn't
> > get enough traffic usually to care about IO.
> >
> > (sorry, getting a bit off topic for the postfix list)
- Цитат от Bron Gondwana (br...@fastmail.fm), на 10.10.2011 в 01:50 -
> On Mon, Oct 10, 2011 at 01:33:31AM +0300, karave...@mail.bg wrote:
>> Nice setup. And thanks for your work on Cyrus. We are
>> looking also to move the metadata on SSDs but we have not
>> found yet cost effective d
--
From: "Bron Gondwana"
Sent: Sunday, October 09, 2011 6:28 PM
To: "vg_ us"
Cc: "Bron Gondwana" ; "Stan Hoeppner"
;
Subject: Re: Premature "No Space left on device" on XFS
On Sun, Oct 09, 20
On 10/9/2011 3:29 PM, Bron Gondwana wrote:
> I'm honestly more interested in maildir type workload too, spool doesn't
> get enough traffic usually to care about IO.
>
> (sorry, getting a bit off topic for the postfix list)
Maybe not off topic. You're delivering into the maildir mailboxes with
l
On Mon, Oct 10, 2011 at 01:49:44AM +0300, karave...@mail.bg wrote:
> I do not trust Postmark - it models mbox appending and skips
> fsync-s. So it is too different from our setup. The best benchmark
> tool I have found is imaptest (from dovecot fame) - it is actually
> end to end benchmarking, in
On Mon, Oct 10, 2011 at 01:33:31AM +0300, karave...@mail.bg wrote:
> Nice setup. And thanks for your work on Cyrus. We are
> looking also to move the metadata on SSDs but we have not
> found yet cost effective devices - we need at least a pair of
> 250G disk for 20-30T spool on a server.
You ca
- Цитат от Bron Gondwana (br...@fastmail.fm), на 10.10.2011 в 01:28 -
> On Sun, Oct 09, 2011 at 04:42:25PM -0400, vg_ us wrote:
>> From: "Bron Gondwana"
>> >I'm honestly more interested in maildir type workload too, spool doesn't
>> >get enough traffic usually to care about IO.
>>
>> wil
On Sun, Oct 09, 2011 at 04:42:25PM -0400, vg_ us wrote:
> will postmark transaction test do? here -
> http://www.phoronix.com/scan.php?page=article&item=linux_2639_fs&num=1
Oh:
http://blog.goolamabbas.org/2007/06/17/postmark-is-not-a-mail-server-benchmark/
"Thus it pains me a lot that they ar
- Цитат от Bron Gondwana (br...@fastmail.fm), на 10.10.2011 в 01:12 -
>
> Here's what our current IMAP servers look like:
>
> 2 x 92GB SSD
> 12 x 2TB SATA
>
> two of the SATA drives are hotspares - though I'm
> wondering if that's actually necessary now, we
> haven't lost any yet, and we
On Sun, Oct 09, 2011 at 04:42:25PM -0400, vg_ us wrote:
> From: "Bron Gondwana"
> >I'm honestly more interested in maildir type workload too, spool doesn't
> >get enough traffic usually to care about IO.
>
> will postmark transaction test do? here -
> http://www.phoronix.com/scan.php?page=articl
On Sun, Oct 09, 2011 at 03:24:44PM -0500, Stan Hoeppner wrote:
> That said, there are plenty of mailbox
> servers in the wild that would benefit from the XFS + linear concat
> setup. It doesn't require an insane drive count, such as the 136 in the
> test system above, to demonstrate the gains, esp
- Цитат от Bron Gondwana (br...@fastmail.fm), на 09.10.2011 в 23:29 -
>
> My goodness. That's REALLY recent in filesystem times. Something
> that recent plus "all my eggs in one basket" of changing to a
> large multi-spindle filesystem that would really get the benefits
> of XFS would be
--
From: "Bron Gondwana"
Sent: Sunday, October 09, 2011 4:29 PM
To: "Stan Hoeppner"
Cc:
Subject: Re: Premature "No Space left on device" on XFS
On Sun, Oct 09, 2011 at 02:31:19PM -0500, Stan Hoeppner wrot
On Sun, Oct 09, 2011 at 02:31:19PM -0500, Stan Hoeppner wrote:
> On 10/9/2011 8:36 AM, Bron Gondwana wrote:
> > How many people are running their mail servers on 24-32 SAS spindles
> > verses those running them on two spindles in RAID1?
>
> These results are for a maildir type workload, i.e. POP/I
On 10/9/2011 9:32 AM, Wietse Venema wrote:
> Stan Hoeppner:
>> On 10/8/2011 3:33 PM, Wietse Venema wrote:
>>> That's a lot of text. How about some hard numbers?
>>
>> Maybe not the perfect example, but here's one such high concurrency
>> synthetic mail server workload comparison showing XFS with a
On 10/9/2011 8:36 AM, Bron Gondwana wrote:
>> http://btrfs.boxacle.net/repository/raid/history/History_Mail_server_simulation._num_threads=128.html
>
> Sorry - I don't see unlinks there. Maybe I'm not not reading very
> carefully...
Unfortunately the web isn't littered with a gazillion head-to-
Stan Hoeppner:
> On 10/8/2011 3:33 PM, Wietse Venema wrote:
> > That's a lot of text. How about some hard numbers?
>
> Maybe not the perfect example, but here's one such high concurrency
> synthetic mail server workload comparison showing XFS with a substantial
> lead over everything but JFS, in w
On Sun, Oct 09, 2011 at 03:56:39AM -0500, Stan Hoeppner wrote:
> On 10/8/2011 3:33 PM, Wietse Venema wrote:
> > That's a lot of text. How about some hard numbers?
>
> Maybe not the perfect example, but here's one such high concurrency
> synthetic mail server workload comparison showing XFS with a
On 10/8/2011 3:33 PM, Wietse Venema wrote:
> Stan Hoeppner:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> On 10/8/2011 5:17 AM, Wietse Venema wrote:
>>> Stan Hoeppner:
nicely. On the other hand, you won't see an EXTx filesystem capable of
anywhere close to 10GB/s or greater file
On 2011-10-07 15:51, Bernhard Schmidt wrote:
Am 07.10.2011 12:12, schrieb Reindl Harald:
Am 07.10.2011 10:41, schrieb Bernhard Schmidt:
Basically the only problem with postfix here is that I cannot have
queue_minfree> 2GB to be on the safe side, so I don't know how to avoid
this problem
have
Stan Hoeppner:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 10/8/2011 5:17 AM, Wietse Venema wrote:
> > Stan Hoeppner:
> >> nicely. On the other hand, you won't see an EXTx filesystem capable of
> >> anywhere close to 10GB/s or greater file IO. Here XFS doesn't break a
> >> sweat.
> >
On 10/8/2011 5:17 AM, Wietse Venema wrote:
> Stan Hoeppner:
>> nicely. On the other hand, you won't see an EXTx filesystem capable of
>> anywhere close to 10GB/s or greater file IO. Here XFS doesn't break a
>> sweat.
>
> I recall that XFS was optimized for fast read/write with large
> files, whi
On Sat, Oct 08, 2011 at 06:17:19AM -0400, Wietse Venema wrote:
> Stan Hoeppner:
> > nicely. On the other hand, you won't see an EXTx filesystem capable of
> > anywhere close to 10GB/s or greater file IO. Here XFS doesn't break a
> > sweat.
>
> I recall that XFS was optimized for fast read/write
Stan Hoeppner:
> nicely. On the other hand, you won't see an EXTx filesystem capable of
> anywhere close to 10GB/s or greater file IO. Here XFS doesn't break a
> sweat.
I recall that XFS was optimized for fast read/write with large
files, while email files are small, and have a comparatively hig
On 10/7/2011 2:50 PM, Bernhard Schmidt wrote:
> On 07.10.2011 21:20, Stan Hoeppner wrote:
>
>> If I may make a purely subjective comment: 2.5m spooled emails on a
>> single host is insane.
>
> I'm not arguing that. In the end the system is supposed to cope with
> 300k mails in 24h, balanced on t
On 07.10.2011 21:20, Stan Hoeppner wrote:
If I may make a purely subjective comment: 2.5m spooled emails on a
single host is insane.
I'm not arguing that. In the end the system is supposed to cope with
300k mails in 24h, balanced on two servers, which I think can be
achieved without a lot o
On Fri, Oct 07, 2011 at 02:20:06PM -0500, Stan Hoeppner wrote:
> If I may make a purely subjective comment: 2.5m spooled emails on a
> single host is insane.
I tested this scale some years back, it was actually the motivation
for adding SMTP connection caching to Postfix ~2.1. If one's bulk
engi
On 10/7/2011 3:41 AM, Bernhard Schmidt wrote:
> Basically the only problem with postfix here is that I cannot have
> queue_minfree > 2GB to be on the safe side, so I don't know how to avoid
> this problem.
There is a simple solution here, Comp Sci 101 type stuff, which Wietse
has mentioned many t
Zitat von Bernhard Schmidt :
Am 07.10.2011 16:01, schrieb lst_ho...@kwsoft.de:
Someone on the XFS mailinglist believed it could be filesystem
fragmentation after all. They need an aligned continous 16k block to
allocate a new inode chunk, otherwise it will fail. I'm going to test
that later.
Am 07.10.2011 16:01, schrieb lst_ho...@kwsoft.de:
>> Someone on the XFS mailinglist believed it could be filesystem
>> fragmentation after all. They need an aligned continous 16k block to
>> allocate a new inode chunk, otherwise it will fail. I'm going to test
>> that later.
>
> This could be che
Zitat von Bernhard Schmidt :
Hi,
It's not the number of inodes as it is common on ext2/ext3 but the
percentage of space occupied by inodes which is dependant on the inode
size, the number and the size of the volume. Check with xfs_info, on the
filesystems we are using xfs on the percentage is
Am 07.10.2011 12:12, schrieb Reindl Harald:
> Am 07.10.2011 10:41, schrieb Bernhard Schmidt:
>> Basically the only problem with postfix here is that I cannot have
>> queue_minfree > 2GB to be on the safe side, so I don't know how to avoid
>> this problem
> have you considered using ext4 instead of
Am 07.10.2011 10:41, schrieb Bernhard Schmidt:
> Basically the only problem with postfix here is that I cannot have
> queue_minfree > 2GB to be on the safe side, so I don't know how to avoid
> this problem
have you considered using ext4 instead of XFS?
signature.asc
Description: OpenPGP dig
Hi,
> It's not the number of inodes as it is common on ext2/ext3 but the
> percentage of space occupied by inodes which is dependant on the inode
> size, the number and the size of the volume. Check with xfs_info, on the
> filesystems we are using xfs on the percentage is 25% but it may be
> diffe
Zitat von Bernhard Schmidt :
On 06.10.2011 22:49, lst_ho...@kwsoft.de wrote:
Hi,
lxmhs45:/var/spool/postfix-bulk/postfix-bulkinhss # touch a
touch: cannot touch `a': No space left on device
lxmhs45:/var/spool/postfix-bulk/postfix-bulkinhss # df .
Filesystem 1K-blocks Used Available Use% Moun
On 06.10.2011 22:49, lst_ho...@kwsoft.de wrote:
Hi,
lxmhs45:/var/spool/postfix-bulk/postfix-bulkinhss # touch a
touch: cannot touch `a': No space left on device
lxmhs45:/var/spool/postfix-bulk/postfix-bulkinhss # df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb 10475520 7471160
Zitat von Bernhard Schmidt :
Hey,
a small not-quite but a bit postfix related issue.
We (or better said: an over-eager third party) have been running
some performance tests against our future outbound bulkmail platform
(no, not UCE, university stuff), which consists of multiple SLES11.1
43 matches
Mail list logo
