With 1.3.39, typically 16 bytes are lost forever in the parent process at child process creation with the ap_table_set(). Did anyone work through a rationalization of this?
Perhaps we could say that 8MB is the amount by which the size of the parent could grow in three months before causing undue interest (i.e., wasting investigation time)... That allows around 500,000 process creations to leak 16 bytes each in the three months, which is around 5000 process creations a day. 5000 process creations a day doesn't seem at all out of range for a busy 1.3 server on Unix. 8MB doesn't seem out of range for growth for a closely watched server. 3 months doesn't seem at all longer than a desirable uptime. I don't see any hashing of keys for speedy lookups in 1.3 ap_table_get() to jpotentially ustify the memory overhead. Alternative opinions? -- Born in Roswell... married an alien...
