ahmad riza h nst put forth on 11/8/2010 7:31 AM: > On Mon, Nov 8, 2010 at 7:25 PM, Stan Hoeppner <s...@hardwarefreak.com> wrote: >> ahmad riza h nst put forth on 11/8/2010 4:08 AM:
>> "Have to"? There are alternatives, such as >> http://www.ispconfig.org/ispconfig-3/ >> >> In the absence of Virtualmin support for your mysql user db, how are you >> going to populate the local UNIX user account database on the new >> system? Does a tool already exist allowing you to do so? If not, and >> you will have to write such a tool, I suggest you focus your efforts on >> writing a tool/plugin to allow Virtualmin to directly read/write your >> mysql user db. > > actually the user isn't there yet, i ask these questions in order what > if in the future our customer emails reach to some thousands users > (like on the other servers), no email to migrate or to create at this > moment, so at this time i don't need to migrate any user from mysql to > unix system user. > we just need to know/understand any limitations or possible problems > in the future if we choose to go on with this setup. I had assumed from your emails that you were planning on migrating, not just adding new users. However, from a management point of view, wouldn't it make sense to keep all of your logon accounts stored in a single location? If at some point down the road you decide to create a POP/IMAP server cluster, it would be highly beneficial to have all of your user credentials housed in a single database server such as mysql, pgsql, or ldap. This is but one example. There a dozens of very good reasons to put logon credentials on a database instead of in the UNIX password file on a local system. > the users mainly use pop to access their emails. > i understand about what imap can do to the system, we have another > servers with lots of user (thousands) running qmail vpopmail that just > find to carry that loads and then i think postfix and dovecot can do > it too, thats what i mean. > yes we don't have any experience on postfix dovecot, but i don't think > there are any gap on performance compare to qmail vpopmail, or it is ? IMAP will put _MUCH_ more load on a system than POP, as I explained previously, especially if you offer webmail access to IMAP, and especially again if you don't use an IMAP proxy between the web servers and the IMAP server. With POP, a user logs on, fetches all new mail, and logs off. So there is only load while the emails are being transmitted. With IMAP, the user logs on, and stays logged on, eating up 5-10MB of RAM for each user. While the user is connected (has Thunderbird open), each time the user clicks on something, a command is sent to the IMAP server. The server then accesses the mailbox folder, pulls the email, and sends it to the client. Each time a new mail arrives, using the IDLE feature, the new email is pushed out to the client MUA. The client can perform a BODY search of all emails in an IMAP folder. Depending on the size of the folder, this can eat 100% of one CPU core many seconds. As the search is processed, the user's IMAP daemon process can grow upwards of 250MB or more in size, depending on the size of the IMAP folder being searched. If you have 4 IMAP users doing a body search simultaneously, this can bog down all 4 CPU cores and eat up between 500MB and 1GB or RAM, or more. This will degrade performance for all of the other IMAP users. Coincidentally, I just performed a body search of a Dovecot IMAP folder with 11,749 messages in it. It consumed 249MB RAM and took 45 seconds to run. This is with the Dovecot FTS_SQUAT plugin enabled, which makes body searches faster once the index is primed. It was not primed when I started my search. Unless you write a script to prime it via a cron job, it will most usually not be primed. Again, an IMAP server needs much more CPU, RAM, and disk spindles than POP due to the nature of the access patterns of the clients. If you get much over 100 concurrent IMAP users on that box with just two mirrored disks you WILL have performance problems. The IOPS of two mirrored disks is the same as a single disk. A single disk can't keep up with 100 concurrent users, even if it's a 15k SAS drive. Single disk IOPS for drives of this class are between 150-180 seeks/second. For each folder/email operation a user performs in the MUA: 1. The mbox or maildir file will be accessed 2. The index files will be read of written to For each inbound email into Postfix delivered via Dovecot LDA: 1. The email moves through two Postfix queue directories 2. The email is written to the mbox or maildir file 3. The Dovecot imap index file is updated 4. Multiple writes are made to the log file by Postfix I've probably missed a few disk writes above. But, as you can see, there is a lot of disk activity involved in running an IMAP server, specifically Dovecot, that isn't involved with a POP server. The index files are what make Dovecot so much faster than other IMAP servers. Indexes aren't need for POP servers as they yield no performance benefit. Again, if you're planning on having a few hundred concurrent IMAP users connected to this server, you need more memory and much more IOPS and bandwidth in your disk subsystem. Memory and disk drives are cheap. Taking the server down later after it's in production is costly. Add the memory and the disks and setup the filesystem layout now, properly, to give the server the IOPS performance it will need, and to prevent downtime and on the fly re-engineering down the road. If you plan to run a webmail server such as Roundcube on this host, connecting via IMAP to Dovecot, you will need the 2nd CPU installed now, not later, and you should probably install 16GB of total RAM in the machine now as well. Webmail servers eat up a lot of RAM and a lot of CPU with many concurrent users logged in. If you add 200 concurrent webmail users on top of the 200 or so normal concurrent IMAP users (Thunderbird, Outlook Express), a dual socket quad core Xeon with 16GB RAM and 8x15k SAS disks in RAID5 may not be fast enough to yield an acceptably responsive user experience. YMMV. But, you try to host that many concurrent users on the machine with one CPU, 4GB RAM, and a single (mirrored) disk, and your customers will being running to another provider in a hurry. Unless you're a monopoly there in Jakarta. :) -- Stan
