Tìm kiếm
40 kết quả cho “OOM”. Tìm không phân biệt dấu.
- What we learned from an iOS app OOMs incident Bài tóm tắt · Pinterest · 2021
…m.com/pinterest-engineering/what-we-learned-from-an-ios-app-ooms-incident-eb31eada251) Bối cảnh - Đầu 2020: crash out-of-memory trên app iOS tăng mạnh; tỉ lệ người dùng không gặp c…
- How We Improved Our Performance Using ElasticSearch Plugins: Part 2 Bài tóm tắt · Tinder · 2019
…u bằng đo: terms (gốc), hash set (to hơn cả giá trị thô), Bloom filter và RoaringBitmap (cả hai nhỏ hơn nhiều). Bloom nhanh hơn chút nhưng có dương tính giả, tức bỏ nhầm người; chọ…
- Building the Activity Graph, Part 2 Bài tóm tắt · LinkedIn · 2017
…riêng trên mỗi searcher node: EntityFeatureStore (EFS) = Bloom filter + cache Caffeine + RocksDB. Mỗi request cần hàng trăm nghìn lookup, nên lookup phải tính bằng nano giây. - Kh…
- How we made ClickStack 5x faster for ClickHouse observability Bài tóm tắt · ClickHouse · 2026
…đơn giản. - Text index (inverted, kết quả chính xác) thay bloom filter cho body log và TraceId: bloom filter có dương tính giả nên vẫn phải đọc và kiểm granule; text index loại chí…
- Using the Gini Coefficient to Plan Edge Capacity Bài tóm tắt · Fastly · 2026
…→ dự đoán cache hit ratio (front-end) → dự đoán CPU → headroom . - Cache: a·sqrt(gini) + b·top N ratio + c , robust regression trên lịch sử gần; căn bậc hai vì những dấu hiệu tập…
- Uncached I/O in Prometheus Bài tóm tắt · Prometheus · 2026
…rss ; chọn sai thì giới hạn bộ nhớ nói dối và container bị OOMKill (có một issue Kubernetes mở 9 năm về chuyện này). Lý do: page cache có thể chiếm phần lớn "bộ nhớ đang dùng" dù…
- Quantifying infrastructure noise in agentic coding evals Bài tóm tắt · Anthropic · 2026
…cho đột biến ngắn: một lần bộ nhớ nhảy lên là container bị OOM-kill dù lẽ ra làm xong. Nhà cung cấp sandbox của bảng xếp hạng thì cho vượt tạm thời. - Đo ảnh hưởng: chạy Terminal-…
- How LinkedIn extended ClickHouse from distributed tracing to metric discovery and analytics Bài tóm tắt · ClickHouse · 2026
…trường thật sự hay query, chỉnh tỉ lệ dương tính giả của Bloom filter ở cột rẻ: query dưới 2 giây. Phần 2: metadata của metric (2025–2026) - Di sản RRDtool: mỗi metric vẫn được gọ…
- Atlas: Our journey from a Python monolith to a managed platform Bài tóm tắt · Dropbox · 2021
…Kayenta), tự dừng và rollback; autoscaler giữ trên 40% headroom mỗi cluster theo độ dài hàng đợi request từ Envoy, vì nhiều cluster nhỏ mất khả năng hấp thụ spike của cluster chung…
- What it takes to run Stack Overflow Bài tóm tắt · Stack Overflow · 2013
…15% CPU, SQL Server 5–10% CPU (2013). Phần dư dùng làm headroom khi có query hỏng, code lỗi hay tấn công, và để chưa phải nâng cấp khi tăng trưởng. - Theo tác giả, nguyên nhân chín…
- The process: Implementing Yelp's failover strategy Bài tóm tắt · Yelp · 2021
…; scale lúc khẩn cấp là quá chậm và có thể hỏng (). - Headroom có thể "miễn phí" nếu rải đều thay vì để máy dự phòng ngồi không. - Biến right-sizing thành mặc định tự động, đi từ…
- When The Cloud Gets Dark — How Amazon's Outage Affected Airbnb Bài tóm tắt · Airbnb · 2011
Toàn bộ hạ tầng Airbnb năm 2011 trên AWS. Sự cố us-east tháng 4/2011: mạng ở hai AZ mất kết nối, EBS tự re-mirror nhưng không đủ capacity dự phòng, volume EBS treo hoặc I/O cực chậm.
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) Chủ đề Thành viên
Từ 2026 các công ty bắt đầu giao cho coding agent những việc trước đây là dự án nhiều tuần: migrate hàng trăm module hay dataset, dọn feature flag, viết lại cả framework hay app. Agent viết nhanh, nhưng ba thứ không tự…
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Pinterest Công ty Thành viên
Năm 2015 Pinterest sinh sẵn nội dung cho mọi user và lưu trong HBase, cách đã đưa họ tới 100 triệu MAU nhưng tốn lưu trữ và khó thử nghiệm. Họ xây 9 hệ thống C++/RocksDB để sinh feed lúc đọc . Phía dưới là tầng cache…
- Wix Inbox Journey: 3 Approaches for Zero Downtime Database Migration Bài tóm tắt · Wix · 2021
…icroservice. - Vì sao không ổn định: - partition key = chatroom id , mà các phòng chat không đều về traffic lẫn dung lượng, nên tạo hot spot , có node crash; - mẫu truy cập mới khô…
- Scaling StreamHub: Transitioning from Kinesis to Kafka for 145 Billion Daily Events Bài tóm tắt · Atlassian · 2026
…được, nên đĩa local đầy dần. 2. Tiered storage vẫn cần headroom local: copy lên S3 chậm lại thì đĩa local tăng tuyến tính. 3. Giới hạn request rate của S3: tăng retention từ 7 lên…
- Fastly Công ty Thành viên
Nguồn duy nhất của Fastly trong wiki là về capacity planning ở edge: mỗi POP chạy lẫn nhiều loại tải trên phần cứng nhiều đời nên không có một con số capacity. Năm 2026 Fastly mô tả mô hình đã chạy production hơn một…
- Autoscaling Monzo: How we optimise our platform to be just the right size Bài tóm tắt · Monzo · 2020
…hiệu quả (càng nhỏ càng rẻ) và khả năng chịu đựng (cần headroom). Thay đổi chính - Vertical Pod Autoscaler (VPA) : recommender dựng mô hình từ CPU/RAM thực dùng và gợi ý request; u…
- Scaling Slack's Job Queue Bài tóm tắt · Slack · 2017
…hải can thiệp tay nhiều. - Postmortem chỉ ra: Redis ít headroom; mọi client nối tới mọi Redis (đồ thị hai phía đầy đủ); thêm worker là thêm poll lên Redis đang quá tải (muốn tăng c…
- Apache Hudi at Uber: Engineering for Trillion-Record-Scale Data Lake Operations Bài tóm tắt · Uber · 2026
…danh sách file, thống kê cột (min/max mỗi file Parquet), bloom filter; list thư mục thành một lượt tra khoá. Đã bật cho hơn 90% dataset. - Record Index (RI): upsert phải tìm đúng…
- How We Made QStash And Upstash Workflow Reliable At Scale Bài tóm tắt · Upstash · 2026
…là bộ nhớ tăng vọt trong khoảng rất ngắn, process tiến tới OOM nhanh hơn tốc độ thêm máy, rồi thành crash loop. - Một goroutine theo dõi heap; vượt ngưỡng (theo memory limit của m…
- From Homegrown to Flink: Migrating a Stateful Ad Event Join at Scale Bài tóm tắt · Zalando · 2026
…cale; phải chặn bằng annotation hoặc PodDisruptionBudget. - OOM do kernel giết (không phải Java OOM): RocksDB dùng native memory, và cấu hình auto-tuning gợi ý là sai. Họ tăng pod…
- Scaling Production Globally — The service mesh facelift (Part-1) Bài tóm tắt · Achievers · 2022
…: khi cụm lớn dần, gke-metrics-agent (do Google quản lý) bị OOM, HPA thỉnh thoảng ngừng chạy; Google không đổi được limit của deployment managed, lại dính bug với máy lớn nhiều pod…
- Load Testing Kubernetes: Resolving bottlenecks and improving performance (Part 2) Bài tóm tắt · Achievers · 2023
…namespace quan trọng vượt limit bộ nhớ của Kubernetes và bị OOM, sửa bằng tăng request. Theo Achievers, Redis không nên là phụ thuộc bắt buộc nhưng service nào dựa nhiều vào cache…
- Disaster Recovery for Databases: High-availability Architecture of PolarDB-X Bài tóm tắt · Alibaba · 2026
…ểu replication. Khung khái niệm - Bốn mức rủi ro : process (OOM, segfault; xác suất cao, ảnh hưởng một service) → máy (kernel panic, hỏng đĩa) → data center (mất điện, đứt cáp) → t…