这是indexloc提供的服务,不要输入任何密码
Skip to content
This repository was archived by the owner on Jan 22, 2025. It is now read-only.

Conversation

@sakridge
Copy link
Contributor

No description provided.

@sakridge sakridge requested a review from mvines September 22, 2018 18:16
@sakridge sakridge merged commit 3199f17 into solana-labs:master Sep 22, 2018
@sakridge sakridge deleted the add-boot-disk-opt branch September 22, 2018 23:43
vkomenda pushed a commit to vkomenda/solana that referenced this pull request Aug 29, 2021
…na-labs#1308)

Bumps [rollup](https://github.com/rollup/rollup) from 2.39.0 to 2.39.1.
- [Release notes](https://github.com/rollup/rollup/releases)
- [Changelog](https://github.com/rollup/rollup/blob/master/CHANGELOG.md)
- [Commits](rollup/rollup@v2.39.0...v2.39.1)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
jeffwashington pushed a commit to jeffwashington/solana that referenced this pull request May 13, 2024
…s#1308)

We were accidentally doing several thousands 4MB allocations - even
during incremental hash - which added up to a 8G+ memory spikes over ~2s
every ~30s.

Fix by using Vec::new() in the identity function. Empirically 98%+
reduces join arrays with less than 128 elements, and only the last few
reduces join large vecs. Because realloc does exponential growth we
don't see pathological reallocation but reduces do at most one realloc
(and often 0 because of exp growth).
willhickey pushed a commit that referenced this pull request Jun 17, 2024
…kport of #1308) (#1318)

accounts-db: fix 8G+ memory spike during hash calculation (#1308)

We were accidentally doing several thousands 4MB allocations - even
during incremental hash - which added up to a 8G+ memory spikes over ~2s
every ~30s.

Fix by using Vec::new() in the identity function. Empirically 98%+
reduces join arrays with less than 128 elements, and only the last few
reduces join large vecs. Because realloc does exponential growth we
don't see pathological reallocation but reduces do at most one realloc
(and often 0 because of exp growth).

(cherry picked from commit 2c71685)

Co-authored-by: Alessandro Decina <alessandro.d@gmail.com>
willhickey pushed a commit that referenced this pull request Jun 17, 2024
…kport of #1308) (#1318)

accounts-db: fix 8G+ memory spike during hash calculation (#1308)

We were accidentally doing several thousands 4MB allocations - even
during incremental hash - which added up to a 8G+ memory spikes over ~2s
every ~30s.

Fix by using Vec::new() in the identity function. Empirically 98%+
reduces join arrays with less than 128 elements, and only the last few
reduces join large vecs. Because realloc does exponential growth we
don't see pathological reallocation but reduces do at most one realloc
(and often 0 because of exp growth).

(cherry picked from commit 2c71685)

Co-authored-by: Alessandro Decina <alessandro.d@gmail.com>
willhickey pushed a commit to willhickey/solana that referenced this pull request Jun 21, 2024
…kport of solana-labs#1308) (solana-labs#1318)

accounts-db: fix 8G+ memory spike during hash calculation (solana-labs#1308)

We were accidentally doing several thousands 4MB allocations - even
during incremental hash - which added up to a 8G+ memory spikes over ~2s
every ~30s.

Fix by using Vec::new() in the identity function. Empirically 98%+
reduces join arrays with less than 128 elements, and only the last few
reduces join large vecs. Because realloc does exponential growth we
don't see pathological reallocation but reduces do at most one realloc
(and often 0 because of exp growth).

(cherry picked from commit 2c71685)

Co-authored-by: Alessandro Decina <alessandro.d@gmail.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants