博客 / 列表

Greptime - 單集羣 100 節點！資源佔用遠小於 Grafana Mimir——GreptimeDB 海量數據寫入性能報告

GreptimeDB 在行業標準測試 Prometheus-Benchmark 當中以 100 個 8c16g 規格節點的集羣，在 datanode 峯值水位為 CPU 38%、內存 40% 的負載下，承接了每秒約 4000 萬點的寫入流量。總體活躍時間線 6.1 億條，每十分鐘更新 615 萬條時間線，在測試的 1.5 小時內均能穩定寫入。 測試結果説明 GreptimeDB 的架構設計能夠支

運維 , rust , 存儲 , 數據庫 , 性能

Greptime - 混沌工程：是誰揹着我偷偷寫 Bug 🤸

前言 GreptimeDB 支持以單機和分佈式的形式進行部署，但緊隨而來一個尖鋭的問題：我們對投入生產的這套複雜系統有多少信心？ 在 0.3 到 0.4 的迭代過程中，我們引入了混沌工程（Chaos engineering）來提高系統的健壯性。 混沌工程是怎麼實施的 我們選擇了 Chaos Mesh 作為故障注入工具。我們在 Pod 中運行一個測試程序（Testcase），該程序通過定義 CR（C

系統設計 , 時序數據庫 , 數據庫 , 開源 , 後端

Greptime - 一文教會你！如何利用火焰圖快速定位內存泄漏？

從 greptimedb#1733 開始，GreptimeDB 使用 Jemalloc 作為默認的內存分配器，這不僅有助於提升性能和降低內存碎片，也提供了便捷的內存分析功能。在 記一次 Rust 內存泄漏排查之旅 | 經驗總結篇 這篇文章中，我們介紹了分析 Rust 應用內存泄漏的幾種常用方法，而在本文中將詳細介紹基於 Jemalloc 的排查手段。 當您在使用或者開發 GreptimeDB 的過

時序數據庫 , 內存泄漏 , 數據庫 , SQL , 後端

Greptime - 記一次 Rust 內存泄漏排查之旅 | 經驗總結篇

在某次持續壓測過程中，我們發現 GreptimeDB 的 Frontend 節點內存即使在請求量平穩的階段也在持續上漲，直至被 OOM kill。我們判斷 Frontend 應該是有內存泄漏了，於是開啓了排查內存泄漏之旅。 Heap Profiling 大型項目幾乎不可能只通過看代碼就能找到內存泄漏的地方。所以我們首先要對程序的內存用量做統計分析。幸運的是，GreptimeDB 使用的 jemal

rust , 時序數據庫 , 內存泄漏 , 數據庫 , 後端

Greptime - AWS EC2 必知必會小技巧 | 機型特點解析和選型技巧分享

背景 AWS EC2 是 AWS 的彈性計算服務，為廣大開發者提供簡單便捷彈性的虛擬機，是 AWS 歷史最悠久的服務之一（另外一個是 S3），從 2006 年發佈至今，已經發展了近 17 年曆史。 相信不少剛開始接觸 EC2 的朋友都有如下類似的感受： AWS EC2 的類型實在是太多了（數百種）！我究竟應該選擇哪一種 EC2 機型既能滿足業務需求且不超過預算 ？ EC2 的 CP

amazon-web-services , 工具 , 技巧 , 數據庫 , 後端