メモリセルの寿命を延ばすウェアレベリング
フラッシュメモリのデータ記録部分であるフローティングゲートと、そこに電子を蓄えておくための絶縁膜があることは前回お話ししたとおりですが、その絶縁膜が「消去」「書き込み」の繰り返しによって劣化し、最後には寿命を迎えます。1千～1万回という書き換え可能回数は、一見すると十分な寿命にも感じられるかも知れませんが、用途によってはそうとも限りません。例えば1秒間に1回、特定のデータを書き換えるプログラムが存在した場合、そのプログラムがフラッシュメモリの特定のアドレスに秒単位で現在時間を書き込んだとしますと、秒の最下位ビットは毎秒「0」と「1」を交互に行き来するため、２秒ごとに書き込みと消去が行われます。１時間は3,600秒ですから、1時間あたりの書き換え回数は1,800回となり、1千回の書き換え回数にはわずか30分余りで、1万回でもたった６時間ほどで達することになり、フラッシュメモリのセルが寿命を迎
ElasticsearchのCircuitBreaker - wyukawa's diary
最近Elasticsearch 5.2.2を使っているときにOutOfMemoryが発生したことがあって、そのときにログを見ると下記のようにCircuitBreakerも発動してた。 Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [request] Data too large, data for [<reused_arrays>] would be larger than limit of [19206989414/17.8gb] at org.elasticsearch.common.breaker.ChildMemoryCircuitBreaker.circuitBreak(ChildMemoryCircuitBreaker.java:97) ~[elasticsearch-5.2.2.ja
sar -r でメモリ使用状況を確認する - ablog
# sar -r 00:00:00 kbmemfree kbmemused %memused kbmemshrd kbbuffers kbcached kbswpfree kbswpused %swpused 00:10:00 220216 3875156 94.62 0 289288 1707500 2024592 72536 3.46 00:20:00 215180 3880192 94.75 0 289312 1707672 2024592 72536 3.46 00:30:00 214552 3880820 94.76 0 289340 1707804 2024592 72536 3.46 kbmemfree: 物理メモリの空き容量 kbmemused: 使用中の物理メモリ量 %memused: 物理メモリ使用率 kbbuffers: カーネル内のバッファとして使用されている物理メ
Dockerコンテナで利用できるリソースや権限を制限する（Dockerの最新機能を使ってみよう：第3回） | さくらのナレッジ
「--memory」（もしくは「-m」）オプションでは、そのコンテナが利用できる最大メモリ量を指定できる。指定の際は「k」や「m」、「g」といった単位および「b」（バイト）も利用可能だ。たとえばコンテナが利用できるメモリ量を最大256MBに制限するには、以下のオプションを指定してコンテナを起動すれば良い。 --memory=256mb なお、実際の制限値はOSのページサイズの倍数に丸められるため、指定した値がそのまま制限値になるわけでは無い。たとえば上記のように「--memory=256mb」を指定したコンテナについて「docker stats」コマンドでリソース使用状況を確認すると、メモリのリミット（MEM LIMIT）が「268.4MB」となっていることが分かる。 # docker stats CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/
resin.propertiesの残像に惑わされる - 09
e-Builder からresinを起動してhttp://localhost:8080/imart/loginをたたくと以下のような例外。 net.sf.ehcache.config.InvalidConfigurationException: There is one error in your configuration: * CacheManager configuration: You've assigned more memory to the on-heap than the VM can sustain, please adjust your -Xmx setting accordingly at net.sf.ehcache.config.CacheConfiguration.setupFor(CacheConfiguration.java:1555) ~[ehcache-
Spark Architecture
Edit from 2015/12/17: Memory model described in this article is deprecated starting Apache Spark 1.6+, the new memory model is based on UnifiedMemoryManager and described in this article Over the recent time I’ve answered a series of questions related to ApacheSpark architecture on StackOverflow. All of them seem to be caused by the absence of a good general description of the Spark architecture i
Determining free memory on Linux | Scout APM Blog
When checking the amount of free memory on a Linux server, it’s easy to think you’re running out of memory when you’re not. For example, here’s the output of free -m on a server with 4GB of RAM: With a quick glance, you might start sweating. Only 39 MB of free memory? Put down the antacid – you’ve got a lot more free memory than you think. Memory Caching & Buffers Reading data from a disk is far s
Linux におけるスレッド数の上限 | yunabe.jp
並行 (Concurrent) 処理を実装する方法としてスレッドは非常に強力なツールです。 スレッドを使えば同時に1つの処理しか行えない既存のプログラムに大きな修正を加えることなく、 並行処理を実装することが可能です。 またイベントとコールバックを複雑に組み合わせた非同期的なプログラムに比べて、 同期的なプログラム (例えばファイルの読み込みにコールバックが出てきたりしない普通のプログラム)は プログラムの流れを自然に書くことができ、 可読性・保守性・テスト、デバッグのしやすさの面で遥かに優れています。 スレッドを使うとプログラムをそれほど複雑・難読化にせずに並行処理が実装できます。 一方でスレッドを使った並行処理には欠点もあります。 欠点の1つは、スレッドモデルでは1つの処理に対して1つのスレッドを用意するので、 システムのスレッド数の上限で同時に行える処理の数が決まってしまう点です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
get error 'CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory' · Issue #10536 · nodejs/node · GitHub
https://docs.confluent.io/current/kafka/deployment.html
Invoke-RestMethod High Memory Usage · Issue #5609 · PowerShell/PowerShell
Dockerのリソースの制限（CPU/メモリ）とCPUの動きについてまとめ - Qiita
Apache Spark User List - Setting spark.executor.memory problem