1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
|
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Postfix Queue Scheduler</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
Queue Scheduler</h1>
<hr>
<h2> Disclaimer </h2>
<p> Many of the <i>transport</i>-specific configuration parameters
discussed in this document will not show up in "postconf" command
output before Postfix version 2.9. This limitation applies to many
parameters whose name is a combination of a master.cf service name
such as "relay" and a built-in suffix such as
"_destination_concurrency_limit". </p>
<h2> Overview </h2>
<p> The queue manager is by far the most complex part of the Postfix
mail system. It schedules delivery of new mail, retries failed
deliveries at specific times, and removes mail from the queue after
the last delivery attempt. There are two major classes of mechanisms
that control the operation of the queue manager. </p>
<p> Topics covered by this document: </p>
<ul>
<li> <a href="#concurrency"> Concurrency scheduling</a>, concerned
with the number of concurrent deliveries to a specific destination,
including decisions on when to suspend deliveries after persistent
failures.
<li> <a href="#jobs"> Preemptive scheduling</a>, concerned with
the selection of email messages and recipients for a given destination.
<li> <a href="#credits"> Credits</a>, something this document would not be
complete without.
</ul>
<!--
<p> Once started, the qmgr(8) process runs until "postfix reload"
or "postfix stop". As a persistent process, the queue manager has
to meet strict requirements with respect to code correctness and
robustness. Unlike non-persistent daemon processes, the queue manager
cannot benefit from Postfix's process rejuvenation mechanism that
limit the impact from resource leaks and other coding errors
(translation: replacing a process after a short time covers up bugs
before they can become a problem). </p>
-->
<h2> <a name="concurrency"> Concurrency scheduling </a> </h2>
<p> The following sections document the Postfix 2.5 concurrency
scheduler, after a discussion of the limitations of the earlier
concurrency scheduler. This is followed by results of medium-concurrency
experiments, and a discussion of trade-offs between performance and
robustness. </p>
<p> The material is organized as follows: </p>
<ul>
<li> <a href="#concurrency_drawbacks"> Drawbacks of the existing
concurrency scheduler </a>
<li> <a href="#concurrency_summary_2_5"> Summary of the Postfix 2.5
concurrency feedback algorithm </a>
<li> <a href="#dead_summary_2_5"> Summary of the Postfix 2.5 "dead
destination" detection algorithm </a>
<li> <a href="#pseudo_code_2_5"> Pseudocode for the Postfix 2.5
concurrency scheduler </a>
<li> <a href="#concurrency_results"> Results for delivery to
concurrency limited servers </a>
<li> <a href="#concurrency_discussion"> Discussion of concurrency
limited server results </a>
<li> <a href="#concurrency_limitations"> Limitations of less-than-1
per delivery feedback </a>
<li> <a href="#concurrency_config"> Concurrency configuration
parameters </a>
</ul>
<h3> <a name="concurrency_drawbacks"> Drawbacks of the existing
concurrency scheduler </a> </h3>
<p> From the start, Postfix has used a simple but robust algorithm
where the per-destination delivery concurrency is decremented by 1
after delivery failed due to connection or handshake failure, and
incremented by 1 otherwise. Of course the concurrency is never
allowed to exceed the maximum per-destination concurrency limit.
And when a destination's concurrency level drops to zero, the
destination is declared "dead" and delivery is suspended. </p>
<p> Drawbacks of +/-1 concurrency feedback per delivery are: <p>
<ul>
<li> <p> Overshoot due to exponential delivery concurrency growth
with each pseudo-cohort(*). This can be an issue with high-concurrency
channels. For example, with the default initial concurrency of 5,
concurrency would proceed over time as (5-10-20). </p>
<li> <p> Throttling down to zero concurrency after a single
pseudo-cohort(*) failure. This was especially an issue with
low-concurrency channels where a single failure could be sufficient
to mark a destination as "dead", causing the suspension of further
deliveries to the affected destination. </p>
</ul>
<p> (*) A pseudo-cohort is a number of delivery requests equal to
a destination's delivery concurrency. </p>
<p> The revised concurrency scheduler has a highly modular structure.
It uses separate mechanisms for per-destination concurrency control
and for "dead destination" detection. The concurrency control in
turn is built from two separate mechanisms: it supports less-than-1
feedback per delivery to allow for more gradual concurrency
adjustments, and it uses feedback hysteresis to suppress concurrency
oscillations. And instead of waiting for delivery concurrency to
throttle down to zero, a destination is declared "dead" after a
configurable number of pseudo-cohorts reports connection or handshake
failure. </p>
<h3> <a name="concurrency_summary_2_5"> Summary of the Postfix 2.5
concurrency feedback algorithm </a> </h3>
<p> We want to increment a destination's delivery concurrency when
some (not necessarily consecutive) number of deliveries complete
without connection or handshake failure. This is implemented with
positive feedback g(N) where N is the destination's delivery
concurrency. With g(N)=1 feedback per delivery, concurrency increases
by 1 after each positive feedback event; this gives us the old
scheduler's exponential growth in time. With g(N)=1/N feedback per
delivery, concurrency increases by 1 after an entire pseudo-cohort
N of positive feedback reports; this gives us linear growth in time.
Less-than-1 feedback per delivery and integer truncation naturally
give us hysteresis, so that transitions to larger concurrency happen
every 1/g(N) positive feedback events. </p>
<p> We want to decrement a destination's delivery concurrency when
some (not necessarily consecutive) number of deliveries complete
after connection or handshake failure. This is implemented with
negative feedback f(N) where N is the destination's delivery
concurrency. With f(N)=1 feedback per delivery, concurrency decreases
by 1 after each negative feedback event; this gives us the old
scheduler's behavior where concurrency is throttled down dramatically
after a single pseudo-cohort failure. With f(N)=1/N feedback per
delivery, concurrency backs off more gently. Again, less-than-1
feedback per delivery and integer truncation naturally give us
hysteresis, so that transitions to lower concurrency happen every
1/f(N) negative feedback events. </p>
<p> However, with negative feedback we introduce a subtle twist.
We "reverse" the negative hysteresis cycle so that the transition
to lower concurrency happens at the <b>beginning</b> of a sequence
of 1/f(N) negative feedback events. Otherwise, a correction for
overload would be made too late. This makes the choice of f(N)
relatively unimportant, as borne out by measurements later in this
document. </p>
<p> In summary, the main ingredients for the Postfix 2.5 concurrency
feedback algorithm are a) the option of less-than-1 positive feedback
per delivery to avoid overwhelming servers, b) the option of
less-than-1 negative feedback per delivery to avoid giving up too
fast, c) feedback hysteresis to avoid rapid oscillation, and d) a
"reverse" hysteresis cycle for negative feedback, so that it can
correct for overload quickly. </p>
<h3> <a name="dead_summary_2_5"> Summary of the Postfix 2.5 "dead destination" detection algorithm </a> </h3>
<p> We want to suspend deliveries to a specific destination after
some number of deliveries suffers connection or handshake failure.
The old scheduler declares a destination "dead" when negative (-1)
feedback throttles the delivery concurrency down to zero. With
less-than-1 feedback per delivery, this throttling down would
obviously take too long. We therefore have to separate "dead
destination" detection from concurrency feedback. This is implemented
by introducing the concept of pseudo-cohort failure. The Postfix
2.5 concurrency scheduler declares a destination "dead" after a
configurable number of pseudo-cohorts suffers from connection or
handshake failures. The old scheduler corresponds to the special
case where the pseudo-cohort failure limit is equal to 1. </p>
<h3> <a name="pseudo_code_2_5"> Pseudocode for the Postfix 2.5 concurrency scheduler </a> </h3>
<p> The pseudo code shows how the ideas behind new concurrency
scheduler are implemented as of November 2007. The actual code can
be found in the module qmgr/qmgr_queue.c. </p>
<pre>
Types:
Each destination has one set of the following variables
int concurrency
double success
double failure
double fail_cohorts
Feedback functions:
N is concurrency; x, y are arbitrary numbers in [0..1] inclusive
positive feedback: g(N) = x/N | x/sqrt(N) | x
negative feedback: f(N) = y/N | y/sqrt(N) | y
Initialization:
concurrency = initial_concurrency
success = 0
failure = 0
fail_cohorts = 0
After success:
fail_cohorts = 0
Be prepared for feedback > hysteresis, or rounding error
success += g(concurrency)
while (success >= 1) Hysteresis 1
concurrency += 1 Hysteresis 1
failure = 0
success -= 1 Hysteresis 1
Be prepared for overshoot
if (concurrency > concurrency limit)
concurrency = concurrency limit
Safety:
Don't apply positive feedback unless
concurrency < busy_refcount + init_dest_concurrency
otherwise negative feedback effect could be delayed
After failure:
if (concurrency > 0)
fail_cohorts += 1.0 / concurrency
if (fail_cohorts > cohort_failure_limit)
concurrency = 0
if (concurrency > 0)
Be prepared for feedback > hysteresis, rounding errors
failure -= f(concurrency)
while (failure < 0)
concurrency -= 1 Hysteresis 1
failure += 1 Hysteresis 1
success = 0
Be prepared for overshoot
if (concurrency < 1)
concurrency = 1
</pre>
<h3> <a name="concurrency_results"> Results for delivery to concurrency-limited servers </a> </h3>
<p> Discussions about the concurrency scheduler redesign started
early 2004, when the primary goal was to find alternatives that did
not exhibit exponential growth or rapid concurrency throttling. No
code was implemented until late 2007, when the primary concern had
shifted towards better handling of server concurrency limits. For
this reason we measure how well the new scheduler does this
job. The table below compares mail delivery performance of the old
+/-1 feedback per delivery with several less-than-1 feedback
functions, for different limited-concurrency server scenarios.
Measurements were done with a FreeBSD 6.2 client and with FreeBSD
6.2 and various Linux servers. </p>
<p> Server configuration: </p>
<ul> <li> The mail flow was slowed down with 1 second latency per
recipient ("smtpd_client_restrictions = sleep 1"). The purpose was
to make results less dependent on hardware details, by avoiding
slow-downs by queue file I/O, logging I/O, and network I/O.
<li> Concurrency was limited by the server process limit
("default_process_limit = 5" and "smtpd_client_event_limit_exceptions
= static:all"). Postfix was stopped and started after changing the
process limit, because the same number is also used as the backlog
argument to the listen(2) system call, and "postfix reload" does
not re-issue this call.
<li> Mail was discarded with "local_recipient_maps = static:all" and
"local_transport = discard". The discard action in access maps or
header/body checks
could not be used as it fails to update the in_flow_delay counters.
</ul>
<p> Client configuration: </p>
<ul>
<li> Queue file overhead was minimized by sending one message to a
virtual alias that expanded into 2000 different remote recipients.
All recipients were accounted for according to the maillog file.
The virtual_alias_expansion_limit setting was increased to avoid
complaints from the cleanup(8) server.
<li> The number of deliveries was maximized with
"smtp_destination_recipient_limit = 2". A smaller limit would cause
Postfix to schedule the concurrency per recipient instead of domain,
which is not what we want.
<li> Maximum concurrency was limited with
"smtp_destination_concurrency_limit = 20", and
initial_destination_concurrency was set to the same value.
<li> The positive and negative concurrency feedback hysteresis was
1. Concurrency was incremented by 1 at the END of 1/feedback steps
of positive feedback, and was decremented by 1 at the START of
1/feedback steps of negative feedback.
<li> The SMTP client used the default 30s SMTP connect timeout and
300s SMTP greeting timeout.
</ul>
<h4> Impact of the 30s SMTP connect timeout </h4>
<p> The first results are for a FreeBSD 6.2 server, where our
artificially low listen(2) backlog results in a very short kernel
queue for established connections. The table shows that all deferred
deliveries failed due to a 30s connection timeout, and none failed
due to a server greeting timeout. This measurement simulates what
happens when the server's connection queue is completely full under
load, and the TCP engine drops new connections. </p>
<blockquote>
<table>
<tr> <th>client<br> limit</th> <th>server<br> limit</th> <th>feedback<br>
style</th> <th>connection<br> caching</th> <th>percentage<br>
deferred</th> <th colspan="2">client concurrency<br> average/stddev</th>
<th colspan=2>timed-out in<br> connect/greeting </th> </tr>
<tr> <td align="center" colspan="9"> <hr> </td> </tr>
<tr><td align="center">20</td> <td align="center">5</td> <td
align="center">1/N</td> <td align="center">no</td> <td
align="center">9.9</td> <td align="center">19.4</td> <td
align="center">0.49</td> <td align="center">198</td> <td
align="center">-</td> </tr>
<tr><td align="center">20</td> <td align="center">5</td> <td
align="center">1/N</td> <td align="center">yes</td> <td
align="center">10.3</td> <td align="center">19.4</td> <td
align="center">0.49</td> <td align="center">206</td> <td
align="center">-</td> </tr>
<tr><td align="center">20</td> <td align="center">5</td> <td
align="center">1/sqrt(N)</td> <td align="center">no</td>
<td align="center">10.4</td> <td align="center">19.6</td> <td
align="center">0.59</td> <td align="center">208</td> <td
align="center">-</td> </tr>
<tr><td align="center">20</td> <td align="center">5</td> <td
align="center">1/sqrt(N)</td> <td align="center">yes</td>
<td align="center">10.6</td> <td align="center">19.6</td> <td
align="center">0.61</td> <td align="center">212</td> <td
align="center">-</td> </tr>
<tr><td align="center">20</td> <td align="center">5</td> <td
align="center">1</td> <td align="center">no</td> <td
align="center">10.1</td> <td align="center">19.5</td> <td
align="center">1.29</td> <td align="center">202</td> <td
align="center">-</td> </tr>
<tr><td align="center">20</td> <td align="center">5</td> <td
align="center">1</td> <td align="center">yes</td> <td
align="center">10.8</td> <td align="center">19.3</td> <td
align="center">1.57</td> <td align="center">216</td> <td
align="center">-</td> </tr>
<tr> <td align="center" colspan="9"> <hr> </td> </tr>
</table>
<p> A busy server with a completely full connection queue. N is
the client delivery concurrency. Failed deliveries time out after
30s without completing the TCP handshake. See text for a discussion
of results. </p>
</blockquote>
<h4> Impact of the 300s SMTP greeting timeout </h4>
<p> The next table shows results for a Fedora Core 8 server (results
for RedHat 7.3 are identical). In this case, the artificially small
listen(2) backlog argument does not impact our measurement. The
table shows that practically all deferred deliveries fail after the
300s SMTP greeting timeout. As these timeouts were 10x longer than
with the first measurement, we increased the recipient count (and
thus the running time) by a factor of 10 to keep the results
comparable. The deferred mail percentages are a factor 10 lower
than with the first measurement, because the 1s per-recipient delay
was 1/300th of the greeting timeout instead of 1/30th of the
connection timeout. </p>
<blockquote>
<table>
<tr> <th>client<br> limit</th> <th>server<br> limit</th> <th>feedback<br>
style</th> <th>connection<br> caching</th> <th>percentage<br>
deferred</th> <th colspan="2">client concurrency<br> average/stddev</th>
<th colspan=2>timed-out in<br> connect/greeting </th> </tr>
<tr> <td align="center" colspan="9"> <hr> </td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/N</td> <td align="center">no</td> <td
align="center">1.16</td> <td align="center">19.8</td> <td
align="center">0.37</td> <td align="center">-</td> <td
align="center">230</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/N</td> <td align="center">yes</td> <td
align="center">1.36</td> <td align="center">19.8</td> <td
align="center">0.36</td> <td align="center">-</td> <td
align="center">272</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/sqrt(N)</td> <td align="center">no</td>
<td align="center">1.21</td> <td align="center">19.9</td> <td
align="center">0.23</td> <td align="center">4</td> <td
align="center">238</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/sqrt(N)</td> <td align="center">yes</td>
<td align="center">1.36</td> <td align="center">20.0</td> <td
align="center">0.23</td> <td align="center">-</td> <td
align="center">272</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1</td> <td align="center">no</td> <td
align="center">1.18</td> <td align="center">20.0</td> <td
align="center">0.16</td> <td align="center">-</td> <td
align="center">236</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1</td> <td align="center">yes</td> <td
align="center">1.39</td> <td align="center">20.0</td> <td
align="center">0.16</td> <td align="center">-</td> <td
align="center">278</td> </tr>
<tr> <td align="center" colspan="9"> <hr> </td> </tr>
</table>
<p> A busy server with a non-full connection queue. N is the client
delivery concurrency. Failed deliveries complete at the TCP level,
but time out after 300s while waiting for the SMTP greeting. See
text for a discussion of results. </p>
</blockquote>
<h4> Impact of active server concurrency limiter </h4>
<p> The final concurrency-limited result shows what happens when
SMTP connections don't time out, but are rejected immediately with
the Postfix server's smtpd_client_connection_count_limit feature
(the server replies with a 421 status and disconnects immediately).
Similar results can be expected with concurrency limiting features
built into other MTAs or firewalls. For this measurement we specified
a server concurrency limit and a client initial destination concurrency
of 5, and a server process limit of 10; all other conditions were
the same as with the first measurement. The same result would be
obtained with a FreeBSD or Linux server, because the "pushing back"
is done entirely by the receiving side. </p>
<blockquote>
<table>
<tr> <th>client<br> limit</th> <th>server<br> limit</th> <th>feedback<br>
style</th> <th>connection<br> caching</th> <th>percentage<br>
deferred</th> <th colspan="2">client concurrency<br> average/stddev</th>
<th>theoretical<br>defer rate</th> </tr>
<tr> <td align="center" colspan="9"> <hr> </td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/N</td> <td align="center">no</td> <td
align="center">16.5</td> <td align="center">5.17</td> <td
align="center">0.38</td> <td align="center">1/6</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/N</td> <td align="center">yes</td> <td
align="center">16.5</td> <td align="center">5.17</td> <td
align="center">0.38</td> <td align="center">1/6</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/sqrt(N)</td> <td align="center">no</td>
<td align="center">24.5</td> <td align="center">5.28</td> <td
align="center">0.45</td> <td align="center">1/4</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1/sqrt(N)</td> <td align="center">yes</td>
<td align="center">24.3</td> <td align="center">5.28</td> <td
align="center">0.46</td> <td align="center">1/4</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1</td> <td align="center">no</td> <td
align="center">49.7</td> <td align="center">5.63</td> <td
align="center">0.67</td> <td align="center">1/2</td> </tr>
<tr> <td align="center">20</td> <td align="center">5</td> <td
align="center">1</td> <td align="center">yes</td> <td
align="center">49.7</td> <td align="center">5.68</td> <td
align="center">0.70</td> <td align="center">1/2</td> </tr>
<tr> <td align="center" colspan="9"> <hr> </td> </tr>
</table>
<p> A server with active per-client concurrency limiter that replies
with 421 and disconnects. N is the client delivery concurrency.
The theoretical defer rate is 1/(1+roundup(1/feedback)). This is
always 1/2 with the fixed +/-1 feedback per delivery; with the
concurrency-dependent feedback variants, the defer rate decreases
with increasing concurrency. See text for a discussion of results.
</p>
</blockquote>
<h3> <a name="concurrency_discussion"> Discussion of concurrency-limited server results </a> </h3>
<p> All results in the previous sections are based on the first
delivery runs only; they do not include any second etc. delivery
attempts. It's also worth noting that the measurements look at
steady-state behavior only. They don't show what happens when the
client starts sending at a much higher or lower concurrency.
</p>
<p> The first two examples show that the effect of feedback
is negligible when concurrency is limited due to congestion. This
is because the initial concurrency is already at the client's
concurrency maximum, and because there is 10-100 times more positive
than negative feedback. Under these conditions, it is no surprise
that the contribution from SMTP connection caching is also negligible.
</p>
<p> In the last example, the old +/-1 feedback per delivery will
defer 50% of the mail when confronted with an active (anvil-style)
server concurrency limit, where the server hangs up immediately
with a 421 status (a TCP-level RST would have the same result).
Less aggressive feedback mechanisms fare better than more aggressive
ones. Concurrency-dependent feedback fares even better at higher
concurrencies than shown here, but has limitations as discussed in
the next section. </p>
<h3> <a name="concurrency_limitations"> Limitations of less-than-1 per delivery feedback </a> </h3>
<p> Less-than-1 feedback is of interest primarily when sending large
amounts of mail to destinations with active concurrency limiters
(servers that reply with 421, or firewalls that send RST). When
sending small amounts of mail per destination, less-than-1 per-delivery
feedback won't have a noticeable effect on the per-destination
concurrency, because the number of deliveries to the same destination
is too small. You might just as well use zero per-delivery feedback
and stay with the initial per-destination concurrency. And when
mail deliveries fail due to congestion instead of active concurrency
limiters, the measurements above show that per-delivery feedback
has no effect. With large amounts of mail you might just as well
use zero per-delivery feedback and start with the maximal per-destination
concurrency. </p>
<p> The scheduler with less-than-1 concurrency
feedback per delivery solves a problem with servers that have active
concurrency limiters. This works only because feedback is handled
in a peculiar manner: positive feedback will increment the concurrency
by 1 at the <b>end</b> of a sequence of events of length 1/feedback,
while negative feedback will decrement concurrency by 1 at the
<b>beginning</b> of such a sequence. This is how Postfix adjusts
quickly for overshoot without causing lots of mail to be deferred.
Without this difference in feedback treatment, less-than-1 feedback
per delivery would defer 50% of the mail, and would be no better
in this respect than the old +/-1 feedback per delivery. </p>
<p> Unfortunately, the same feature that corrects quickly for
concurrency overshoot also makes the scheduler more sensitive for
noisy negative feedback. The reason is that one lonely negative
feedback event has the same effect as a complete sequence of length
1/feedback: in both cases delivery concurrency is dropped by 1
immediately. As a worst-case scenario, consider multiple servers
behind a load balancer on a single IP address, and no backup MX
address. When 1 out of K servers fails to complete the SMTP handshake
or drops the connection, a scheduler with 1/N (N = concurrency)
feedback stops increasing its concurrency once it reaches a concurrency
level of about K, even though the good servers behind the load
balancer are perfectly capable of handling more traffic. </p>
<p> This noise problem gets worse as the amount of positive feedback
per delivery gets smaller. A compromise is to use fixed less-than-1
positive feedback values instead of concurrency-dependent positive
feedback. For example, to tolerate 1 of 4 bad servers in the above
load balancer scenario, use positive feedback of 1/4 per "good"
delivery (no connect or handshake error), and use an equal or smaller
amount of negative feedback per "bad" delivery. The downside of
using concurrency-independent feedback is that some of the old +/-1
feedback problems will return at large concurrencies. Sites that
must deliver mail at non-trivial per-destination concurrencies will
require special configuration. </p>
<h3> <a name="concurrency_config"> Concurrency configuration parameters </a> </h3>
<p> The Postfix 2.5 concurrency scheduler is controlled with the
following configuration parameters, where "<i>transport</i>_foo"
provides a transport-specific parameter override. All parameter
default settings are compatible with earlier Postfix versions. </p>
<blockquote>
<table border="0">
<tr> <th> Parameter name </th> <th> Postfix version </th> <th>
Description </th> </tr>
<tr> <td colspan="3"> <hr> </td> </tr>
<tr> <td> initial_destination_concurrency<br>
<i>transport</i>_initial_destination_concurrency </td> <td
align="center"> all<br> 2.5 </td> <td> Initial per-destination
delivery concurrency </td> </tr>
<tr> <td> default_destination_concurrency_limit<br>
<i>transport</i>_destination_concurrency_limit </td> <td align="center">
all<br> all </td> <td> Maximum per-destination delivery concurrency
</td> </tr>
<tr> <td> default_destination_concurrency_positive_feedback<br>
<i>transport</i>_destination_concurrency_positive_feedback </td>
<td align="center"> 2.5<br> 2.5 </td> <td> Per-destination positive
feedback amount, per delivery that does not fail with connection
or handshake failure </td> </tr>
<tr> <td> default_destination_concurrency_negative_feedback<br>
<i>transport</i>_destination_concurrency_negative_feedback </td>
<td align="center"> 2.5<br> 2.5 </td> <td> Per-destination negative
feedback amount, per delivery that fails with connection or handshake
failure </td> </tr>
<tr> <td> default_destination_concurrency_failed_cohort_limit<br>
<i>transport</i>_destination_concurrency_failed_cohort_limit </td>
<td align="center"> 2.5<br> 2.5 </td> <td> Number of failed
pseudo-cohorts after which a destination is declared "dead" and
delivery is suspended </td> </tr>
<tr> <td> destination_concurrency_feedback_debug</td> <td align="center">
2.5 </td> <td> Enable verbose logging of concurrency scheduler
activity </td> </tr>
<tr> <td colspan="3"> <hr> </td> </tr>
</table>
</blockquote>
<h2> <a name="jobs"> Preemptive scheduling </a> </h2>
<p>
The following sections describe the new queue manager and its
preemptive scheduler algorithm. Note that the document was originally
written to describe the changes between the new queue manager (in
this text referred to as <tt>nqmgr</tt>, the name it was known by
before it became the default queue manager) and the old queue manager
(referred to as <tt>oqmgr</tt>). This is why it refers to <tt>oqmgr</tt>
every so often.
</p>
<p>
This document is divided into sections as follows:
</p>
<ul>
<li> <a href="#<tt>nqmgr</tt>_structures"> The structures used by
nqmgr </a>
<li> <a href="#<tt>nqmgr</tt>_pickup"> What happens when nqmgr picks
up the message </a> - how it is assigned to transports, jobs, peers,
entries
<li> <a href="#<tt>nqmgr</tt>_selection"> How the entry selection
works </a>
<li> <a href="#<tt>nqmgr</tt>_preemption"> How the preemption
works </a> - what messages may be preempted and how and what messages
are chosen to preempt them
<li> <a href="#<tt>nqmgr</tt>_concurrency"> How destination concurrency
limits affect the scheduling algorithm </a>
<li> <a href="#<tt>nqmgr</tt>_memory"> Dealing with memory resource
limits </a>
</ul>
<h3> <a name="<tt>nqmgr</tt>_structures"> The structures used by
nqmgr </a> </h3>
<p>
Let's start by recapitulating the structures and terms used when
referring to the queue manager and how it operates. Many of these are
partially described elsewhere, but it is nice to have a coherent
overview in one place:
</p>
<ul>
<li> <p> Each message structure represents one mail message which
Postfix is to deliver. The message recipients specify to what
destinations is the message to be delivered and what transports are
going to be used for the delivery. </p>
<li> <p> Each recipient entry groups a batch of recipients of one
message which are all going to be delivered to the same destination
(and over the same transport).
</p>
<li> <p> Each transport structure groups everything what is going
to be delivered by delivery agents dedicated for that transport.
Each transport maintains a set of queues (describing the destinations
it shall talk to) and jobs (referencing the messages it shall
deliver). </p>
<li> <p> Each transport queue (not to be confused with the on-disk
"active" queue or "incoming" queue) groups everything what is going be
delivered to given destination (aka nexthop) by its transport. Each
queue belongs to one transport, so each destination may be referred
to by several queues, one for each transport. Each queue maintains
a list of all recipient entries (batches of message recipients)
which shall be delivered to given destination (the todo list), and
a list of recipient entries already being delivered by the delivery
agents (the busy list). </p>
<li> <p> Each queue corresponds to multiple peer structures. Each
peer structure is like the queue structure, belonging to one transport
and referencing one destination. The difference is that it lists
only the recipient entries which all originate from the same message,
unlike the queue structure, whose entries may originate from various
messages. For messages with few recipients, there is usually just
one recipient entry for each destination, resulting in one recipient
entry per peer. But for large mailing list messages the recipients
may need to be split to multiple recipient entries, in which case
the peer structure may list many entries for single destination.
</p>
<li> <p> Each transport job groups everything it takes to deliver
one message via its transport. Each job represents one message
within the context of the transport. The job belongs to one transport
and message, so each message may have multiple jobs, one for each
transport. The job groups all the peer structures, which describe
the destinations the job's message has to be delivered to. </p>
</ul>
<p>
The first four structures are common to both <tt>nqmgr</tt> and
<tt>oqmgr</tt>, the latter two were introduced by <tt>nqmgr</tt>.
</p>
<p>
These terms are used extensively in the text below, feel free to
look up the description above anytime you'll feel you have lost a
sense what is what.
</p>
<h3> <a name="<tt>nqmgr</tt>_pickup"> What happens when nqmgr picks
up the message </a> </h3>
<p>
Whenever <tt>nqmgr</tt> moves a queue file into the "active" queue,
the following happens: It reads all necessary information from the
queue file as <tt>oqmgr</tt> does, and also reads as many recipients
as possible - more on that later, for now let's just pretend it
always reads all recipients.
</p>
<p>
Then it resolves the recipients as <tt>oqmgr</tt> does, which
means obtaining (address, nexthop, transport) triple for each
recipient. For each triple, it finds the transport; if it does not
exist yet, it instantiates it (unless it's dead). Within the
transport, it finds the destination queue for the given nexthop; if it
does not exist yet, it instantiates it (unless it's dead). The
triple is then bound to given destination queue. This happens in
qmgr_resolve() and is basically the same as in <tt>oqmgr</tt>.
</p>
<p>
Then for each triple which was bound to some queue (and thus
transport), the program finds the job which represents the message
within that transport's context; if it does not exist yet, it
instantiates it. Within the job, it finds the peer which represents
the bound destination queue within this jobs context; if it does
not exist yet, it instantiates it. Finally, it stores the address
from the resolved triple to the recipient entry which is appended
to both the queue entry list and the peer entry list. The addresses
for the same nexthop are batched in the entries up to the
<i>transport</i>_destination_recipient_limit for that transport.
This happens in qmgr_message_assign(), and apart
from that it operates with job and peer structures, it is basically the
same as in <tt>oqmgr</tt>.
</p>
<p>
When the job is instantiated, it is enqueued on the transport's job
list based on the time its message was picked up by <tt>nqmgr</tt>.
For first batch of recipients this means it is appended to the end
of the job list, but the ordering of the job list by the enqueue
time is important as we will see shortly.
</p>
<p>
[Now you should have a pretty good idea what the state of the
<tt>nqmgr</tt> is after a couple of messages were picked up, and what the
relation is between all those job, peer, queue and entry structures.]
</p>
<h3> <a name="<tt>nqmgr</tt>_selection"> How the entry selection
works </a> </h3>
<p>
Having prepared all those above mentioned structures, the task of
the <tt>nqmgr</tt>'s scheduler is to choose the recipient entries
one at a time and pass them to the delivery agent for corresponding
transport. Now how does this work?
</p>
<p>
The first approximation of the new scheduling algorithm is like this:
</p>
<blockquote>
<pre>
foreach transport (round-robin-by-transport)
do
if transport busy continue
if transport process limit reached continue
foreach transport's job (in the order of the transport's job list)
do
foreach job's peer (round-robin-by-destination)
if peer->queue->concurrency < peer->queue->window
return next peer entry.
done
done
done
</pre>
</blockquote>
<p>
Now what is the "order of the transport's job list"? As we know
already, the job list is by default kept in the order the message
was picked up by the <tt>nqmgr</tt>. So by default we get the
top-level round-robin transport, and within each transport we get
the FIFO message delivery. The round-robin of the peers by the
destination is perhaps of little importance in most real-life cases
(unless the <i>transport</i>_destination_recipient_limit is reached,
in one job there
is only one peer structure for each destination), but theoretically
it makes sure that even within single jobs, destinations are treated
fairly.
</p>
<p>
[By now you should have a feeling you really know how the scheduler
works, except for the preemption, under ideal conditions - that is,
no recipient resource limits and no destination concurrency problems.]
</p>
<h3> <a name="<tt>nqmgr</tt>_preemption"> How the preemption
works </a> </h3>
<p>
As you might perhaps expect by now, the transport's job list does
not remain sorted by the job's message enqueue time all the time.
The most cool thing about <tt>nqmgr</tt> is not the simple FIFO
delivery, but that it is able to slip mail with little recipients
past the mailing-list bulk mail. This is what the job preemption
is about - shuffling the jobs on the transport's job list to get
the best message delivery rates. Now how is it achieved?
</p>
<p>
First I have to tell you that there are in fact two job lists in
each transport. One is the scheduler's job list, which the scheduler
is free to play with, while the other one keeps the jobs always
listed in the order of the enqueue time and is used for recipient
pool management we will discuss later. For now, we will deal with
the scheduler's job list only.
</p>
<p>
So, we have the job list, which is first ordered by the time the
jobs' messages were enqueued, oldest messages first, the most recently
picked one at the end. For now, let's assume that there are no
destination concurrency problems. Without preemption, we pick some
entry of the first (oldest) job on the queue, assign it to delivery
agent, pick another one from the same job, assign it again, and so
on, until all the entries are used and the job is delivered. We
would then move onto the next job and so on and on. Now how do we
manage to sneak in some entries from the recently added jobs when
the first job on the job list belongs to a message going to the
mailing-list and has thousands of recipient entries?
</p>
<p>
The <tt>nqmgr</tt>'s answer is that we can artificially "inflate"
the delivery time of that first job by some constant for free - it
is basically the same trick you might remember as "accumulation of
potential" from the amortized complexity lessons. For example,
instead of delivering the entries of the first job on the job list
every time a delivery agent becomes available, we can do it only
every second time. If you view the moments the delivery agent becomes
available on a timeline as "delivery slots", then instead of using
every delivery slot for the first job, we can use only every other
slot, and still the overall delivery efficiency of the first job
remains the same. So the delivery <tt>11112222</tt> becomes
<tt>1.1.1.1.2.2.2.2</tt> (1 and 2 are the imaginary job numbers, .
denotes the free slot). Now what do we do with free slots?
</p>
<p>
As you might have guessed, we will use them for sneaking the mail
with little recipients in. For example, if we have one four-recipient
mail followed by four one recipients mail, the delivery sequence
(that is, the sequence in which the jobs are assigned to the
delivery slots) might look like this: <tt>12131415</tt>. Hmm, fine
for sneaking in the single recipient mail, but how do we sneak in
the mail with more than one recipient? Say if we have one four-recipient
mail followed by two two-recipient mails?
</p>
<p>
The simple answer would be to use delivery sequence <tt>12121313</tt>.
But the problem is that this does not scale well. Imagine you have
mail with a thousand recipients followed by mail with a hundred recipients.
It is tempting to suggest the delivery sequence like <tt>121212....</tt>,
but alas! Imagine there arrives another mail with say ten recipients.
But there are no free slots anymore, so it can't slip by, not even
if it had only one recipient. It will be stuck until the
hundred-recipient mail is delivered, which really sucks.
</p>
<p>
So, it becomes obvious that while inflating the message to get
free slots is a great idea, one has to be really careful of how the
free slots are assigned, otherwise one might corner himself. So,
how does <tt>nqmgr</tt> really use the free slots?
</p>
<p>
The key idea is that one does not have to generate the free slots
in a uniform way. The delivery sequence <tt>111...1</tt> is no
worse than <tt>1.1.1.1</tt>, in fact, it is even better as some
entries are in the first case selected earlier than in the second
case, and none is selected later! So it is possible to first
"accumulate" the free delivery slots and then use them all at once.
It is even possible to accumulate some, then use them, then accumulate
some more and use them again, as in <tt>11..1.1</tt> .
</p>
<p>
Let's get back to the one hundred recipient example. We now know
that we could first accumulate one hundred free slots, and only
after then to preempt the first job and sneak the one hundred
recipient mail in. Applying the algorithm recursively, we see the
hundred recipient job can accumulate ten free delivery slots, and
then we could preempt it and sneak in the ten-recipient mail...
Wait wait wait! Could we? Aren't we overinflating the original one
thousand recipient mail?
</p>
<p>
Well, despite the fact that it looks so at the first glance, another trick will
allow us to answer "no, we are not!". If we had said that we will
inflate the delivery time twice at maximum, and then we consider
every other slot as a free slot, then we would overinflate in case
of the recursive preemption. BUT! The trick is that if we use only
every n-th slot as a free slot for n>2, there is always some worst
inflation factor which we can guarantee not to be breached, even
if we apply the algorithm recursively. To be precise, if for every
k>1 normally used slots we accumulate one free delivery slot, than
the inflation factor is not worse than k/(k-1) no matter how many
recursive preemptions happen. And it's not worse than (k+1)/k if
only non-recursive preemption happens. Now, having got through the
theory and the related math, let's see how <tt>nqmgr</tt> implements
this.
</p>
<p>
Each job has so called "available delivery slot" counter. Each
transport has a <i>transport</i>_delivery_slot_cost parameter, which
defaults to default_delivery_slot_cost parameter which is set to 5
by default. This is the k from the paragraph above. Each time k
entries of the job are selected for delivery, this counter is
incremented by one. Once there are some slots accumulated, a job which
requires no more than that number of slots to be fully delivered
can preempt this job.
</p>
<p>
[Well, the truth is, the counter is incremented every time an entry
is selected and it is divided by k when it is used.
But to understand, it's good enough to use
the above approximation of the truth.]
</p>
<p>
OK, so now we know the conditions which must be satisfied so one
job can preempt another one. But what job gets preempted, how do
we choose what job preempts it if there are several valid candidates,
and when does all this exactly happen?
</p>
<p>
The answer for the first part is simple. The job whose entry was
selected the last time is the so called current job. Normally, it is
the first job on the scheduler's job list, but destination concurrency
limits may change this as we will see later. It is always only the
current job which may get preempted.
</p>
<p>
Now for the second part. The current job has a certain amount of
recipient entries, and as such may accumulate at maximum some amount
of available delivery slots. It might have already accumulated some,
and perhaps even already used some when it was preempted before
(remember a job can be preempted several times). In either case,
we know how many are accumulated and how many are left to deliver,
so we know how many it may yet accumulate at maximum. Every other
job which may be delivered by less than that number of slots is a
valid candidate for preemption. How do we choose among them?
</p>
<p>
The answer is - the one with maximum enqueue_time/recipient_entry_count.
That is, the older the job is, the more we should try to deliver
it in order to get best message delivery rates. These rates are of
course subject to how many recipients the message has, therefore
the division by the recipient (entry) count. No one shall be surprised
that a message with n recipients takes n times longer to deliver than
a message with one recipient.
</p>
<p>
Now let's recap the previous two paragraphs. Isn't it too complicated?
Why don't the candidates come only among the jobs which can be
delivered within the number of slots the current job already
accumulated? Why do we need to estimate how much it has yet to
accumulate? If you found out the answer, congratulate yourself. If
we did it this simple way, we would always choose the candidate
with the fewest recipient entries. If there were enough single recipient
mails coming in, they would always slip by the bulk mail as soon
as possible, and the two or more recipients mail would never get
a chance, no matter how long they have been sitting around in the
job list.
</p>
<p>
This candidate selection has an interesting implication - that when
we choose the best candidate for preemption (this is done in
qmgr_choose_candidate()), it may happen that we may not use it for
preemption immediately. This leads to an answer to the last part
of the original question - when does the preemption happen?
</p>
<p>
The preemption attempt happens every time next transport's recipient
entry is to be chosen for delivery. To avoid needless overhead, the
preemption is not attempted if the current job could never accumulate
more than <i>transport</i>_minimum_delivery_slots (defaults to
default_minimum_delivery_slots which defaults to 3). If there are
already enough accumulated slots to preempt the current job by the
chosen best candidate, it is done immediately. This basically means
that the candidate is moved in front of the current job on the
scheduler's job list and decreasing the accumulated slot counter
by the amount used by the candidate. If there are not enough slots...
well, I could say that nothing happens and the another preemption
is attempted the next time. But that's not the complete truth.
</p>
<p>
The truth is that it turns out that it is not really necessary to
wait until the jobs counter accumulates all the delivery slots in
advance. Say we have ten-recipient mail followed by two two-recipient
mails. If the preemption happened when enough delivery slots accumulate
(assuming slot cost 2), the delivery sequence becomes
<tt>11112211113311</tt>. Now what would we get if we would wait
only for 50% of the necessary slots to accumulate and we promise
we would wait for the remaining 50% later, after we get back
to the preempted job? If we use such a slot loan, the delivery sequence
becomes <tt>11221111331111</tt>. As we can see, it makes it not
considerably worse for the delivery of the ten-recipient mail, but
it allows the small messages to be delivered sooner.
</p>
<p>
The concept of these slot loans is where the
<i>transport</i>_delivery_slot_discount and
<i>transport</i>_delivery_slot_loan come from (they default to
default_delivery_slot_discount and default_delivery_slot_loan, whose
values are by default 50 and 3, respectively). The discount (resp.
loan) specifies how many percent (resp. how many slots) one "gets
in advance", when the number of slots required to deliver the best
candidate is compared with the number of slots the current slot had
accumulated so far.
</p>
<p>
And that pretty much concludes this chapter.
</p>
<p>
[Now you should have a feeling that you pretty much understand the
scheduler and the preemption, or at least that you will have
after you read the last chapter a couple more times. You shall clearly
see the job list and the preemption happening at its head, in ideal
delivery conditions. The feeling of understanding shall last until
you start wondering what happens if some of the jobs are blocked,
which you might eventually figure out correctly from what had been
said already. But I would be surprised if your mental image of the
scheduler's functionality is not completely shattered once you
start wondering how it works when not all recipients may be read
in-core. More on that later.]
</p>
<h3> <a name="<tt>nqmgr</tt>_concurrency"> How destination concurrency
limits affect the scheduling algorithm </a> </h3>
<p>
The <tt>nqmgr</tt> uses the same algorithm for destination concurrency
control as <tt>oqmgr</tt>. Now what happens when the destination
limits are reached and no more entries for that destination may be
selected by the scheduler?
</p>
<p>
From the user's point of view it is all simple. If some of the peers
of a job can't be selected, those peers are simply skipped by the
entry selection algorithm (the pseudo-code described before) and
only the selectable ones are used. If none of the peers may be
selected, the job is declared a "blocker job". Blocker jobs are
skipped by the entry selection algorithm and they are also excluded
from the candidates for preemption of the current job. Thus the scheduler
effectively behaves as if the blocker jobs didn't exist on the job
list at all. As soon as at least one of the peers of a blocker job
becomes unblocked (that is, the delivery agent handling the delivery
of the recipient entry for the given destination successfully finishes),
the job's blocker status is removed and the job again participates
in all further scheduler actions normally.
</p>
<p>
So the summary is that the users don't really have to be concerned
about the interaction of the destination limits and scheduling
algorithm. It works well on its own and there are no knobs they
would need to control it.
</p>
<p>
From a programmer's point of view, the blocker jobs complicate the
scheduler quite a lot. Without them, the jobs on the job list would
be normally delivered in strict FIFO order. If the current job is
preempted, the job preempting it is completely delivered unless it
is preempted itself. Without blockers, the current job is thus
always either the first job on the job list, or the top of the stack
of jobs preempting the first job on the job list.
</p>
<p>
The visualization of the job list and the preemption stack without
blockers would be like this:
</p>
<blockquote>
<pre>
first job-> 1--2--3--5--6--8--... <- job list
on job list |
4 <- preemption stack
|
current job-> 7
</pre>
</blockquote>
<p>
In the example above we see that job 1 was preempted by job 4 and
then job 4 was preempted by job 7. After job 7 is completed, remaining
entries of job 4 are selected, and once they are all selected, job
1 continues.
</p>
<p>
As we see, it's all very clean and straightforward. Now how does
this change because of blockers?
</p>
<p>
The answer is: a lot. Any job may become a blocker job at any time,
and also become a normal job again at any time. This has several
important implications:
</p>
<ol>
<li> <p>
The jobs may be completed in arbitrary order. For example, in the
example above, if the current job 7 becomes blocked, the next job
4 may complete before the job 7 becomes unblocked again. Or if both
7 and 4 are blocked, then 1 is completed, then 7 becomes unblocked
and is completed, then 2 is completed and only after that 4 becomes
unblocked and is completed... You get the idea.
</p>
<p>
[Interesting side note: even when jobs are delivered out of order,
from a single destination's point of view the jobs are still delivered
in the expected order (that is, FIFO unless there was some preemption
involved). This is because whenever a destination queue becomes
unblocked (the destination limit allows selection of more recipient
entries for that destination), all jobs which have peers for that
destination are unblocked at once.]
</p>
<li> <p>
The idea of the preemption stack at the head of the job list is
gone. That is, it must be possible to preempt any job on the job
list. For example, if the jobs 7, 4, 1 and 2 in the example above
become all blocked, job 3 becomes the current job. And of course
we do not want the preemption to be affected by the fact that there
are some blocked jobs or not. Therefore, if it turns out that job
3 might be preempted by job 6, the implementation shall make it
possible.
</p>
<li> <p>
The idea of the linear preemption stack itself is gone. It's no
longer true that one job is always preempted by only one job at one
time (that is directly preempted, not counting the recursively
nested jobs). For example, in the example above, job 1 is directly
preempted by only job 4, and job 4 by job 7. Now assume job 7 becomes
blocked, and job 4 is being delivered. If it accumulates enough
delivery slots, it is natural that it might be preempted for example
by job 8. Now job 4 is preempted by both job 7 AND job 8 at the
same time.
</p>
</ol>
<p>
Now combine the points 2) and 3) with point 1) again and you realize
that the relations on the once linear job list became pretty
complicated. If we extend the point 3) example: jobs 7 and 8 preempt
job 4, now job 8 becomes blocked too, then job 4 completes. Tricky,
huh?
</p>
<p>
If I illustrate the relations after the above mentioned examples
(but those in point 1), the situation would look like this:
</p>
<blockquote>
<pre>
v- parent
adoptive parent -> 1--2--3--5--... <- "stack" level 0
| |
parent gone -> ? 6 <- "stack" level 1
/ \
children -> 7 8 ^- child <- "stack" level 2
^- siblings
</pre>
</blockquote>
<p>
Now how does <tt>nqmgr</tt> deal with all these complicated relations?
</p>
<p>
Well, it maintains them all as described, but fortunately, all these
relations are necessary only for the purpose of proper counting of
available delivery slots. For the purpose of ordering the jobs for
entry selection, the original rule still applies: "the job preempting
the current job is moved in front of the current job on the job
list". So for entry selection purposes, the job relations remain
as simple as this:
</p>
<blockquote>
<pre>
7--8--1--2--6--3--5--.. <- scheduler's job list order
</pre>
</blockquote>
<p>
The job list order and the preemption parent/child/siblings relations
are maintained separately. And because the selection works only
with the job list, you can happily forget about those complicated
relations unless you want to study the <tt>nqmgr</tt> sources. In
that case the text above might provide some helpful introduction
to the problem domain. Otherwise I suggest you just forget about
all this and stick with the user's point of view: the blocker jobs
are simply ignored.
</p>
<p>
[By now, you should have a feeling that there are more things going
on under the hood than you ever wanted to know. You decide that
forgetting about this chapter is the best you can do for the sake
of your mind's health and you basically stick with the idea how the
scheduler works in ideal conditions, when there are no blockers,
which is good enough.]
</p>
<h3> <a name="<tt>nqmgr</tt>_memory"> Dealing with memory resource
limits </a> </h3>
<p>
When discussing the <tt>nqmgr</tt> scheduler, we have so far assumed
that all recipients of all messages in the "active" queue are completely
read into memory. This is simply not true. There is an upper
bound on the amount of memory the <tt>nqmgr</tt> may use, and
therefore it must impose some limits on the information it may store
in memory at any given time.
</p>
<p>
First of all, not all messages may be read in-core at once. At any
time, only qmgr_message_active_limit messages may be read in-core
at maximum. When read into memory, the messages are picked from the
"incoming" and "deferred" queues and moved to the "active" queue
(incoming having priority), so if there are more than
qmgr_message_active_limit messages queued in the "active" queue, the
rest will have to wait until (some of) the messages in the "active" queue
are completely delivered (or deferred).
</p>
<p>
Even with the limited amount of in-core messages, there is another
limit which must be imposed in order to avoid memory exhaustion.
Each message may contain a huge number of recipients (tens or hundreds
of thousands are not uncommon), so if <tt>nqmgr</tt> read all
recipients of all messages in the "active" queue, it may easily run
out of memory. Therefore there must be some upper bound on the
amount of message recipients which are read into memory at the
same time.
</p>
<p>
Before discussing how exactly <tt>nqmgr</tt> implements the recipient
limits, let's see how the sole existence of the limits themselves
affects the <tt>nqmgr</tt> and its scheduler.
</p>
<p>
The message limit is straightforward - it just limits the size of
the
lookahead the <tt>nqmgr</tt>'s scheduler has when choosing which
message can preempt the current one. Messages not in the "active" queue
are simply not considered at all.
</p>
<p>
The recipient limit complicates more things. First of all, the
message reading code must support reading the recipients in batches,
which among other things means accessing the queue file several
times and continuing where the last recipient batch ended. This is
invoked by the scheduler whenever the current job has space for more
recipients, subject to transport's refill_limit and refill_delay parameters.
It is also done any time when all
in-core recipients of the message are dealt with (which may also
mean they were deferred) but there are still more in the queue file.
</p>
<p>
The second complication is that with some recipients left unread
in the queue file, the scheduler can't operate with exact counts
of recipient entries. With unread recipients, it is not clear how
many recipient entries there will be, as they are subject to
per-destination grouping. It is not even clear to what transports
(and thus jobs) the recipients will be assigned. And with messages
coming from the "deferred" queue, it is not even clear how many unread
recipients are still to be delivered. This all means that the
scheduler must use only estimates of how many recipients entries
there will be. Fortunately, it is possible to estimate the minimum
and maximum correctly, so the scheduler can always err on the safe
side. Obviously, the better the estimates, the better the results, so
it is best when we are able to read all recipients in-core and turn
the estimates into exact counts, or at least try to read as many
as possible to make the estimates as accurate as possible.
</p>
<p>
The third complication is that it is no longer true that the scheduler
is done with a job once all of its in-core recipients are delivered.
It is possible that the job will be revived later, when another
batch of recipients is read in core. It is also possible that some
jobs will be created for the first time long after the first batch
of recipients was read in core. The <tt>nqmgr</tt> code must be
ready to handle all such situations.
</p>
<p>
And finally, the fourth complication is that the <tt>nqmgr</tt>
code must somehow impose the recipient limit itself. Now how does
it achieve it?
</p>
<p>
Perhaps the easiest solution would be to say that each message may
have at maximum X recipients stored in-core, but such a solution would
be poor for several reasons. With reasonable qmgr_message_active_limit
values, the X would have to be quite low to maintain a reasonable
memory footprint. And with low X lots of things would not work well.
The <tt>nqmgr</tt> would have problems to use the
<i>transport</i>_destination_recipient_limit efficiently. The
scheduler's preemption would be suboptimal as the recipient count
estimates would be inaccurate. The message queue file would have
to be accessed many times to read in more recipients again and
again.
</p>
<p>
Therefore it seems reasonable to have a solution which does not use
a limit imposed on a per-message basis, but which maintains a pool
of available recipient slots, which can be shared among all messages
in the most efficient manner. And as we do not want separate
transports to compete for resources whenever possible, it seems
appropriate to maintain such a recipient pool for each transport
separately. This is the general idea, now how does it work in
practice?
</p>
<p>
First we have to solve a little chicken-and-egg problem. If we want
to use the per-transport recipient pools, we first need to know to
what transport(s) the message is assigned. But we will find that
out only after we first read in the recipients. So it is obvious
that we first have to read in some recipients, use them to find out
to what transports the message is to be assigned, and only after
that can we use the per-transport recipient pools.
</p>
<p>
Now how many recipients shall we read for the first time? This is
what qmgr_message_recipient_minimum and qmgr_message_recipient_limit
values control. The qmgr_message_recipient_minimum value specifies
how many recipients of each message we will read the first time,
no matter what. It is necessary to read at least one recipient
before we can assign the message to a transport and create the first
job. However, reading only qmgr_message_recipient_minimum recipients
even if there are only few messages with few recipients in-core would
be wasteful. Therefore if there are fewer than qmgr_message_recipient_limit
recipients in-core so far, the first batch of recipients may be
larger than qmgr_message_recipient_minimum - as large as is required
to reach the qmgr_message_recipient_limit limit.
</p>
<p>
Once the first batch of recipients was read in core and the message
jobs were created, the size of the subsequent recipient batches (if
any - of course it's best when all recipients are read in one batch)
is based solely on the position of the message jobs on their
corresponding transports' job lists. Each transport has a pool of
<i>transport</i>_recipient_limit recipient slots which it can
distribute among its jobs (how this is done is described later).
The subsequent recipient batch may be as large as the sum of all
recipient slots of all jobs of the message permits (plus the
qmgr_message_recipient_minimum amount which always applies).
</p>
<p>
For example, if a message has three jobs, the first with 1 recipient
still in-core and 4 recipient slots, the second with 5 recipients in-core
and 5 recipient slots, and the third with 2 recipients in-core and 0
recipient slots, it has 1+5+2=8 recipients in-core and 4+5+0=9 jobs'
recipients slots in total. This means that we could immediately
read 2+qmgr_message_recipient_minimum more recipients of that message
in core.
</p>
<p>
The above example illustrates several things which might be worth
mentioning explicitly: first, note that although the per-transport
slots are assigned to particular jobs, we can't guarantee that once
the next batch of recipients is read in core, that the corresponding
amounts of recipients will be assigned to those jobs. The jobs lend
its slots to the message as a whole, so it is possible that some
jobs end up sponsoring other jobs of their message. For example,
if in the example above the 2 newly read recipients were assigned
to the second job, the first job sponsored the second job with 2
slots. The second notable thing is the third job, which has more
recipients in-core than it has slots. Apart from sponsoring by other
job we just saw it can be result of the first recipient batch, which
is sponsored from global recipient pool of qmgr_message_recipient_limit
recipients. It can be also sponsored from the message recipient
pool of qmgr_message_recipient_minimum recipients.
</p>
<p>
Now how does each transport distribute the recipient slots among
its jobs? The strategy is quite simple. As most scheduler activity
happens on the head of the job list, it is our intention to make
sure that the scheduler has the best estimates of the recipient
counts for those jobs. As we mentioned above, this means that we
want to try to make sure that the messages of those jobs have all
recipients read in-core. Therefore the transport distributes the
slots "along" the job list from start to end. In this case the job
list sorted by message enqueue time is used, because it doesn't
change over time as the scheduler's job list does.
</p>
<p>
More specifically, each time a job is created and appended to the
job list, it gets all unused recipient slots from its transport's
pool. It keeps them until all recipients of its message are read.
When this happens, all unused recipient slots are transferred to
the next job (which is now in fact the first such job) on the job
list which still has some recipients unread, or eventually back to
the transport pool if there is no such job. Such a transfer then also
happens whenever a recipient entry of that job is delivered.
</p>
<p>
There is also a scenario when a job is not appended to the end of
the job list (for example it was created as a result of a second or
later recipient batch). Then it works exactly as above, except that
if it was put in front of the first unread job (that is, the job
of a message which still has some unread recipients in the queue file),
that job is first forced to return all of its unused recipient slots
to the transport pool.
</p>
<p>
The algorithm just described leads to the following state: The first
unread job on the job list always gets all the remaining recipient
slots of that transport (if there are any). The jobs queued before
this job are completely read (that is, all recipients of their
message were already read in core) and have at maximum as many slots
as they still have recipients in-core (the maximum is there because
of the sponsoring mentioned before) and the jobs after this job get
nothing from the transport recipient pool (unless they got something
before and then the first unread job was created and enqueued in
front of them later - in such a case, they also get at maximum as many
slots as they have recipients in-core).
</p>
<p>
Things work fine in such a state for most of the time, because the
current job is either completely read in-core or has as many recipient
slots as there are, but there is one situation which we still have
to take care of specially. Imagine if the current job is preempted
by some unread job from the job list and there are no more recipient
slots available, so this new current job could read only batches
of qmgr_message_recipient_minimum recipients at a time. This would
really degrade performance. For this reason, each transport has an
extra pool of <i>transport</i>_extra_recipient_limit recipient
slots, dedicated exactly for this situation. Each time an unread
job preempts the current job, it gets half of the remaining recipient
slots from the normal pool and this extra pool.
</p>
<p>
And that's it. It sure does sound pretty complicated, but fortunately
most people don't really have to care exactly how it works as long
as it works. Perhaps the only important things to know for most
people are the following upper bound formulas:
</p>
<p>
Each transport has at maximum
</p>
<blockquote>
<pre>
max(
qmgr_message_recipient_minimum * qmgr_message_active_limit
+ *_recipient_limit + *_extra_recipient_limit,
qmgr_message_recipient_limit
)
</pre>
</blockquote>
<p>
recipients in core.
</p>
<p>
The total amount of recipients in core is
</p>
<blockquote>
<pre>
max(
qmgr_message_recipient_minimum * qmgr_message_active_limit
+ sum( *_recipient_limit + *_extra_recipient_limit ),
qmgr_message_recipient_limit
)
</pre>
</blockquote>
<p>
where the sum is over all used transports.
</p>
<p>
And this terribly complicated chapter concludes the documentation
of the <tt>nqmgr</tt> scheduler.
</p>
<p>
[By now you should theoretically know the <tt>nqmgr</tt> scheduler
inside out. In practice, you still hope that you will never have
to really understand the last or last two chapters completely, and
fortunately most people really won't. Understanding how the scheduler
works in ideal conditions is more than good enough for the vast majority
of users.]
</p>
<h2> <a name="credits"> Credits </a> </h2>
<ul>
<li> Wietse Venema designed and implemented the initial queue manager
with per-domain FIFO scheduling, and per-delivery +/-1 concurrency
feedback.
<li> Patrik Rak designed and implemented preemption where mail with
fewer recipients can slip past mail with more recipients in a
controlled manner, and wrote up its documentation.
<li> Wietse Venema initiated a discussion with Patrik Rak and Victor
Duchovni on alternatives for the +/-1 feedback scheduler's aggressive
behavior. This is when K/N feedback was reviewed (N = concurrency).
The discussion ended without a good solution for both negative
feedback and dead site detection.
<li> Victor Duchovni resumed work on concurrency feedback in the
context of concurrency-limited servers.
<li> Wietse Venema then re-designed the concurrency scheduler in
terms of the simplest possible concepts: less-than-1 concurrency
feedback per delivery, forward and reverse concurrency feedback
hysteresis, and pseudo-cohort failure. At this same time, concurrency
feedback was separated from dead site detection.
<li> These simplifications, and their modular implementation, helped
to develop further insights into the different roles that positive
and negative concurrency feedback play, and helped to identify some
worst-case scenarios.
</ul>
</body>
</html>
|
