Member Avatar for me!

Hello everyone,

I have a server running plesk 10.2.0 with Qmail, inside we host a website and we also run our own mailing list.

For the mailing list we use the software ListMessenger 2.1.0.

We have no issues what so ever with the server, everything runs good even normal user mail.

The issue comes when we send emails to our mailing list which is a DB of around 20,000 people, ListMessenger generates batches and then send email using PHPMail and them emails get delivered to every inbox.

The problem is that it generates 20,000 emails and the email queue gets so big that our server lasts about 2 days to finish delivering emails.

So what's your recommendation to avoid the server getting such a load? should I get a bigger server? I currently have a VPS with 2GB RAM a 1000/100mb share port on the network and not sure about the CPU.

I have monitor theses stats when I sent emails and nothing gets over loaded so the only thing I can tell has too much load is the email queue.

  • 2 Contributors
  • 2 Replies
  • 230 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by me!

Dani AI

Generated

Good call from — the queue behaviour you see is exactly what qmail’s remote-concurrency limit is designed to control. qmail uses the control file concurrencyremote (default 20) to limit simultaneous outbound deliveries, so a big list will end up piling in the queue if that value is low. (man.cx)

Practical, low-risk steps to try first: check the current setting, raise it in small increments, and restart qmail-send. For example:

# check current value
cat /var/qmail/control/concurrencyremote

# change to 60 (example)
echo "60" > /var/qmail/control/concurrencyremote

# restart qmail-send (method depends on your init/supervise system)
svc -t /service/qmail-send
# or
service qmail restart

Adjust gradually (30 → 60 → 90) and watch system load and socket usage while a campaign runs. (support.mailchannels.com)

Caution: raising concurrency helps only up to the point where remote MTAs or upstream ISPs start deferring or throttling your connections. qmail docs warn that too-high concurrency can spawn many qmail-remote processes and may look like abuse to recipient servers; monitor /var/log/qmail/* or your mail log for 4xx/421 deferrals and back off if you see them. Also, if many recipients share the same destination domain, group or slow those batches to avoid opening many simultaneous connections to one host. (flylib.com)

If you need consistently high throughput (20k lists often need it), consider offloading delivery to a reputable SMTP relay/ESP (Amazon SES, SendGrid, etc.) — they handle scale, IP reputation, bounce handling and have documented send-rate quotas and warm‑up processes. Also make sure SPF/DKIM/DMARC are setup and include proper List-Unsubscribe headers to meet modern provider requirements (Gmail, Yahoo, etc.). These steps improve deliverability far more than simply adding RAM/CPU. (docs.aws.amazon.com)

Summary checklist for :

  • Increment concurrencyremote and monitor.
  • Pace batches and avoid huge per-domain bursts.
  • Watch logs for deferrals; reduce concurrency if observed.
  • Consider an ESP for repeat large sends and implement SPF/DKIM/DMARC + List-Unsubscribe.

Recommended Answers

All 2 Replies

Member Avatar for rch1231

Hello,

You could try increasing the number of outgoing queues that qmail is using. By default it is normally 20 remote connections however I run mine at 60 to accommodate one of my clients running a mail list server.

Reference the following qmail page for more information:
http://www.lifewithqmail.org/lwq.html#config-files

Member Avatar for me!

You know what you're totally right didn't think of that! and I guess I can configure mi mailing list program to sent an equal amount of emails on each batch it creates to sent.

I'll definitely give it a try, thanks!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.