Details
-
Improvement
-
Status: Closed
-
Major - P3
-
Resolution: Done
-
None
-
None
-
None
Description
While trying to repro https://jira.mongodb.org/browse/SERVER-20197 I noticed something odd. If I disable compression, the breakdown of time to iterate a table for the first time (pulling it into WT cache) is roughly:
28.84% pread64 (This seem like the unavoidable "real work")
|
21.49% __wt_cksum_hw (WT-2121 should help this)
|
46.00% memset from __wt_realloc from __wt_buf_grow_worker from __wt_block_read_off from __wt_bm_read from __wt_bt_read
|
|
The 46% is split into 37.38% servicing minor pagefaults (which would move somewhere else if we didn't memset) and ~8% in memset itself (which wouldn't).
|
|
The call to memset is prefaced with the following comment:
|
|
/*
|
* Clear the allocated memory -- an application might: allocate memory,
|
* write secret stuff into it, free the memory, then we re-allocate the
|
* memory and use it for a file page or log record, and then write it to
|
* disk. That would result in the secret stuff being protected by the
|
* WiredTiger permission mechanisms, potentially inappropriate for the
|
* secret stuff.
|
*/
|
I don't think this applies to mongod, since if someone has access to the (decrypted) data files they have access to all of the secret data anyway. Would allowing applications to opt-out of this zeroing be an easy way to boost performance or is there some reason why this can't be avoided?
Attachments
Issue Links
- is depended on by
-
SERVER-23140 WiredTiger changes for MongoDB 3.3.4
-
- Closed
-
- links to