| Summary: | segfaults when using mod_mem_cache + mod_disk_cache on a reverse proxy with mod_proxy + mod_proxy_http | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | bpkroth |
| Component: | mod_mem_cache | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED LATER | ||
| Severity: | major | CC: | bpkroth |
| Priority: | P2 | Keywords: | MassUpdate |
| Version: | 2.2.22 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
A test PHP file to help in reproducing the crash.
The coredump backtrace output from the reverse proxy. |
||
|
Description
bpkroth
2014-09-12 16:52:31 UTC
Created attachment 32014 [details]
The coredump backtrace output from the reverse proxy.
Honest opinion: Don't use mod_mem_cache. It does not speed up things compared to mod_disk_cache. mod_mem_cache's cache is not shared between different httpd processes. So you waste more memory for getting less performance. Given that you have enough memory in your server mod_disk_cache content is kept in the buffer caches by the OS. If you don't use SSL stuff is send via sendfile which moves stuff from the buffer caches to the socket directly inside the kernel. If you are using SSL stuff will need to be MMAP which is still very fast. (In reply to Ruediger Pluem from comment #2) > Honest opinion: Don't use mod_mem_cache. It does not speed up things > compared to mod_disk_cache. mod_mem_cache's cache is not shared between > different httpd processes. So you waste more memory for getting less > performance. Given that you have enough memory in your server mod_disk_cache > content is kept in the buffer caches by the OS. If you don't use SSL stuff > is send via sendfile which moves stuff from the buffer caches to the socket > directly inside the kernel. If you are using SSL stuff will need to be MMAP > which is still very fast. Yeah, I don't disagree. Under very high load there is a difference between mod_mem_cache and mod_disk_cache in so far as the latter requires some extra syscalls to the OS for file permissions and handles and the like, which can be particularly expensive in a VM environment, but that is kind of an edge case. (In reply to bpkroth from comment #1) > Created attachment 32014 [details] > The coredump backtrace output from the reverse proxy. I think this crash is the same as my recent question in dev@httpd thread "mod_cache/mod_mem_cache questions" about the difference between remove_url and remove_entity. (In reply to bpkroth from comment #3) > (In reply to Ruediger Pluem from comment #2) > > Honest opinion: Don't use mod_mem_cache. It does not speed up things > > compared to mod_disk_cache. mod_mem_cache's cache is not shared between > > different httpd processes. So you waste more memory for getting less > > performance. Given that you have enough memory in your server mod_disk_cache > > content is kept in the buffer caches by the OS. If you don't use SSL stuff > > is send via sendfile which moves stuff from the buffer caches to the socket > > directly inside the kernel. If you are using SSL stuff will need to be MMAP > > which is still very fast. > > Yeah, I don't disagree. Under very high load there is a difference between > mod_mem_cache and mod_disk_cache in so far as the latter requires some extra > syscalls to the OS for file permissions and handles and the like, which can > be particularly expensive in a VM environment, but that is kind of an edge > case. A good alternative is also to use mod_disk_cache on a directory which a (mounted) ramdisk cache. (In reply to Yann Ylavic from comment #5) > (In reply to bpkroth from comment #3) > > (In reply to Ruediger Pluem from comment #2) > > > Honest opinion: Don't use mod_mem_cache. It does not speed up things > > > compared to mod_disk_cache. mod_mem_cache's cache is not shared between > > > different httpd processes. So you waste more memory for getting less > > > performance. Given that you have enough memory in your server mod_disk_cache > > > content is kept in the buffer caches by the OS. If you don't use SSL stuff > > > is send via sendfile which moves stuff from the buffer caches to the socket > > > directly inside the kernel. If you are using SSL stuff will need to be MMAP > > > which is still very fast. > > > > Yeah, I don't disagree. Under very high load there is a difference between > > mod_mem_cache and mod_disk_cache in so far as the latter requires some extra > > syscalls to the OS for file permissions and handles and the like, which can > > be particularly expensive in a VM environment, but that is kind of an edge > > case. > > A good alternative is also to use mod_disk_cache on a directory which a > (mounted) ramdisk cache. This is a little off topic from what the bug was actually about (errors in mod_mem_cache), but I'll bite. Someone correct me if I'm wrong, but using tmpfs/ramdisk won't avoid your file open(), read()/sendfile(), write(), etc. syscalls from going through the OS to access the cache files instead of just staying in the Apache process space when doing cache lookups. I believe that context switch is what accounts for the performance difference between mod_mem_cache and mod_disk_cache. As Ruediger pointed out, if you have enough memory free, then the OS is already going to do a good job of caching the dirents, inode and data blocks in the page cache anyways, so you shouldn't be seeing any major read performance differences between mod_disk_cache and mod_mem_cache aside from those calls to do the lookups and get handles on the file. Even write performance to the cache shouldn't be too bad given the OS will probably buffer that too and write it out to disk in the background. But I guess the only way to know for sure would be to test it :) All that said, you don't have to convince me not to use mod_mem_cache anymore. Consider this just a heads up that it's broken in some more edge cases. Perhaps a warning to all future users who run across it :) Cheers, Brian Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated. |