超雑にまとめました。修正してください。
登場人物
- アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。
- 後輩: 頼んでばっかしで役に立たない。
- サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。
- プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
この記事は、C++ (fork) Advent Calendar 2013の12日目の記事です。
記事を書く人が居ないみたいなので、C++初心者ですが箸休め的な記事を書こうと思い立ち、いざ書き上げてみたら思いの外長くなりました。
この記事は、C++初心者な著者が、C++を用いて競技プログラミングをするために、調べたことや試した事などのまとめです。 記事中に誤り、問題点やご指摘、ご質問等ありましたら、@rigibunまでご連絡下さい(特にpush_bach)
githubのmarkdownを使いたかったことと、変更履歴が見られることからgistで書きました。
https://prometheus.io/ 2.3.2 (2018-07-12)
exporter 周りは大分充実してきたし、retention period に応じたメモリがある程度あればI/Oがひどいことになることはないので運用はまあまあ簡単だと思う。 時系列データも圧縮されるので、300000 メトリクス・解像度 15 秒・14 日間保存で 50GB ぐらいで済んでる。 PromQL を投げたときに CPU を結構食うので、ルールをたくさん書きたいとかめっちゃ PromQL を眺めたいって時は CPU を積んであげるのがオススメ。
long-term storage 周りはそんなにシュッとはしてないので、基本的には 14d ぐらいの短い周期のデータを解像度高く見たいとか、 そんな真剣に長期のメトリクスを眺めなくていいような時とかに使うのが良いと思う。 (まあ本気を出せば long-term storage もできなくないが、運用コストはまあまあ高まると思う。)