Internet Mail Gateway recieving faster than it can send

[jbru]

Hi,

First of all thumbs up for your product! Like it a lot!

But now I've got a problem. My Internet Mail Gateway has about 20000 mails. It were 40000 after one message hang on sending, but that problem is solved. Only now it's sending very slow. Often we're receiving more mails than it can send in the same period.

The indexing service is sometimes bussy, (50 - 80% cpu) but it doesn't look like this is the problem. I allready used:

IDX_MAXLOAD=1
IDX_MINLOAD=0.5

The messages to be send aren't very big, just text no attachments.

The server I'm using is SuSE Enterprise server 10 and I'm using Scalix 11.4.6 It has got about 200/300 users(?) and about 40 domains. The system has got 1024 MB memory and it's a virtual machine (XEN).

I tried moving the Internet Mail Gateway queue (ROUTER) to a other queue (TEMP) by using omqdump, but when I use the Move option it reports a 'time out request'. So I can not move it

Now I would like to speed up the sending process, but I don't know how and IF it's possible. Other option is moving the queue so I can filter out rubbish and can move back the messages in groups of e.g. 100 mails. Can anyone advice me on this one?

(BTW I'm moving the server to a other server one of these days, but I want a empty queue before moving)

[smpoole7]

The system has got 1024 MB memory and it's a virtual machine (XEN).

You need considerably more memory, IMNHO. That's just for starters. I'd use at least 4 Gigabytes.

With more memory to work with, search the Wiki for performance improvements, such as devoting more memory to Tomcat and other tweaks. But with only 1 Gig, the operating system takes about half of that from the git-go, leaving less than 512 Megabytes for Scalix. (Especially if you're running a GUI in the VM.)

I'm not a big fan of running a high-demand server in a VM, but others will disagree with me, so let's leave that one aside.

[jbru]

Yesterday I wanted to export the whole scalix server to a new one, but it didn't work. I did use SCP for copying to the other server. The dir I copied was /var/opt/scalix, gave same IP and FQDN.

Then did a reinstall of scalix. Gave some problems because the old system was 32 bit and the new one 64 bit. So removed everything but not the information store. Reinstalled it again and still problems. Not accepting passwords for mail users and no sac/webmail. Now the old server has also the same problem though I can login to SAC, but no mailuser can access their mail (webmail/pop3/imap)

See my other post about this problem: http://www.scalix.com/forums/viewtopic.php?f=2&t=17796&p=68168#p68168

If I'm right this was the way to go, but now I've got 2 servers with both no running mailserver. Either the old one or the new one has to work.

Please help!

[jbru]

I had to do something, so I installed a complete empty (new) server and setup all users by hand. Lot of work, but at least it works again!

Thanks for all your support!

[smpoole7]

Glad you got it working. For future reference, you can't just copy Scalix to a new machine and expect it to work. Even if you use the same IP and FQDN, something will get missed and it won't run. The correct way to do it (briefly) is:

1. Install Scalix on the new machine, make sure it works (create a couple of dummy accounts with SAC and use Webmail to send a few test messages between them)

2. Stop all Scalix services, then delete the mailstore on the new machine, which will be in /var/opt/scalix/??/s, where "??" is the first and last letters of the hostname (ex., "mail" gives "ml" for the directory name)

3. Copy the "s" folder from the original PC over to the new one. Use "chown -R scalix.scalix /var/opt/scalix/pp/s" to ensure the ownership. (This is probably what bit you: the owner and group numbers were probably different between the two PCs.)

4. Run "ompatchom" on the new PC.

5. Start the Scalix installer on the new PC, delete the database (answer "yes" when asked), then re-run the installer and re-install/re-create the database. (Obviously, all passwords must be the same, too.)

6. Delete the contents of /var/opt/scalix/??/indexes and /var/opt/scalix/??/s/indexwork.

7. Restart Scalix.

8. Run "sxmkindex" to rebuild the indexes.

That's off the top of my head (can you tell I've done this a few times?), so I might have missed something, but there you go.

By the way ... when I said I'm not in favor of running a high-demand server under virtualization, I should qualify that: it's OK if you have a really, really powerful and fast server. But speaking from experience, I've had trouble running our Scalix in a VM, so I run it directly on the hardware now.

Best of luck.

[kanderson]

Scalix's biggest bottleneck is disk performance. If you're having performance problems, it's usually because you have a crappy disk IO subsystem. Here's what you want.

Raid 10 on lots of 15K SAS Disks.

That's ideal. As you step down (to save money, go in this order.)

First give up the fast disk. So Down to 7200RPM SATA. But keep LOTS of them in a RAID 10. This will be the biggest cost savings, so start here.
Then go to fewer disks. This is a dramatic cut in performance. 8 disks in R10 is about 95% faster than 4 disks in R10. So it's dramatic. Obviously, this is next in saving money.
Give up the onboard cache on the RAID controller and the battery backup (meaning give up write caching).
Then give up Raid 10. This is a last resort. And you'll move to a mirror set, not a RAID 5. This will limit your growth, there's no way around that.
Last resort is Raid 5. This won't perform well past about 50 or 75 users. At this stage, I'd be consitering a hosted option. This is a bad choice, and you WILL pay for it (in $$$ and frustration) as you grow.
The only thing worse than Raid 5 is Raid 6. Please don't do this. Period.

I would advise rethinking your server if you aren't building it on Raid 10 across 6 SATA drives (3 mirror sets) as a minimum. With 300 users, you'll simply always see performance issues otherwise.

I would also agree that 4 Gigs is the right way to go for RAM, but I'd rather find a server starved for RAM than one starved for disk. The fix is easier, faster, and cheaper.
I've never seen a Scalix box that is starved for CPU. I've actually never even heard of it.

Kev.