Tìm kiếm
40 kết quả cho “file system cache”. Tìm không phân biệt dấu.
- Fixing Linux filesystem performance regressions Bài tóm tắt · LinkedIn · 2020
…ốc](https://engineering.linkedin.com/blog/2020/fixing-linux-filesystem-performance-regressions) Bối cảnh - Fleet tăng từ hàng trăm lên hàng trăm nghìn server. Các đợt reimage trước…
- The exabyte club: LinkedIn's journey of scaling the Hadoop Distributed File System Bài tóm tắt · LinkedIn · 2021
…eter rồi xác nhận trên production). - Satellite cluster cho file nhỏ: block 512 MB; tỉ lệ block/file khoảng 1,1 nghĩa là 90% file là file nhỏ. Thư mục /system (log, config của YARN…
- Upscaling LinkedIn's Profile Datastore While Reducing Costs Bài tóm tắt · LinkedIn · 2023
…ốc](https://engineering.linkedin.com/blog/2023/upscaling-profile-datastore-while-reducing-costs) Bối cảnh - Đỉnh 4,8 triệu profile/giây , request tới storage gấp đôi mỗi năm (2023)…
- 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:
- How we accidentally built a better build system for OCaml Bài tóm tắt · Jane Street · 2025
…oài build được code của họ mà không cần Jenga. Jbuilder đọc file jbuild và chạy mọi lệnh biên dịch theo thứ tự topo, chạy lại hết mỗi lần, không phải build system theo nghĩa thông…
- The Chubby lock service for loosely-coupled distributed systems Bài tóm tắt · Google · 2006
…dùng Paxos bầu master; DNS để tìm replica. Giao diện giống file system (file và thư mục, node vĩnh viễn hoặc tạm gắn với session); mỗi file/thư mục là một read/write lock advisory…
- Inside Turbopack: Building Faster by Building Less Bài tóm tắt · Vercel · 2026
…dõi phụ thuộc: kiểu Make khai báo đồ thị tay và cache theo file nên dễ sai và cache thô. Bundler (tree shaking, gom chung) có quan hệ nhiều-nhiều giữa file nguồn và artifact nên c…
- Turbopack: What's New in Next.js 16.3 Bài tóm tắt · Vercel · 2026
Đánh đổi cũ: Turbopack giữ kết quả trong RAM để bớt CPU (compile tỉ lệ với kích thước thay đổi). Theo Vercel, RAM giờ khan vì agent, IDE, typechecker, linter cùng chạy lúc dev.
- Designing a SystemVerilog Language Server Bài tóm tắt · Hudson River Trading · 2026
…lliance là nhanh và tuân chuẩn nhất), goto-definition xuyên file, completion. Parser của extension thành giới hạn. - Viết slang-server , language server dựa trên Slang, dùng được v…
- Next.js 16.1 Bài tóm tắt · Vercel · 2025
Cache đĩa của Turbopack cho next dev ổn định và bật mặc định: artifact của compiler lưu xuống đĩa nên khởi động lại dev server compile nhanh hơn nhiều ở project lớn. Các app nội bộ của Vercel đã dùng thử khoảng một năm;…
- Long on Research, Short on Bandwidth Bài tóm tắt · Hudson River Trading · 2026
…g ; tốc độ chuyển tụt. Log DupeDog không thấy ai mới; cache file phân tán Cashy cũng không. Bộ đếm byte của switch cho thấy một nguồn lạ làm bão hoà đường vào Chicago. Thay đổi chí…
- Inside the Go Playground Bài tóm tắt · Go · 2013
…ive Client (NaCl) , giới hạn CPU, RAM, không có network hay file system. Nhưng Go nổi bật ở concurrency và network; bản đầu thì giờ đứng yên ở 10/11/2009 và time.Sleep không có tác…
- How we designed our continuous integration system to be more than 50% faster Bài tóm tắt · Pinterest · 2021
…bị đổi: CLI Go tên build-collector nhận một tập commit, xem file nào đổi rồi chạy Bazel query ( rdeps để tìm phụ thuộc ngược, lọc kind để lấy target test), xuất danh sách target ra…
- How recurring network maintenance exposed 6 bugs Bài tóm tắt · Jane Street · 2026
…bug 11 năm, từ 2015): res init thất bại giữa chừng (ví dụ EMFILE khi hết file descriptor) để lại resolver nửa khởi tạo; lần tra DNS tiếp theo trên cùng thread segfault. Tái hiện bằ…
- Open sourcing Databus: LinkedIn's low latency change data capture system Bài tóm tắt · LinkedIn · 2013
…nh. - Consumer điển hình: search index, read replica của profile. Bài học cho SWE - Dựng lại một hệ dẫn xuất (index mới) mà không đụng DB chính cần một snapshot nằm ngoài DB chính;…
- Why We're Moving on From Nix (Introducing Railpack) Bài tóm tắt · Railway · 2025
…ID vào mọi build, nên mọi layer sau chỗ biến đó trong Dockerfile luôn bị invalidate. Thay đổi chính - Railpack viết lại từ đầu, đổi từ Rust sang Go (để dùng thư viện BuildKit). Ba…
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Troubleshooting: A journey into the unknown Bài tóm tắt · Booking.com · 2017
…hủ phạm là curl: với HTTPS, thư viện NSS gọi access tới các file không tồn tại tên ngẫu nhiên mỗi lần chạy, sinh dentry mới. Chính health check của anycast-healthchecker gọi curl m…
- A Decade of Evolution of Alibaba's Databases - Part 2 Bài tóm tắt · Alibaba · 2019
…ử nghiệm trên Ceph (2017), song song với Apsara Distributed File System 2.0; - cần network low latency: TCP 25 Gbit/s (2017), rồi RDMA quy mô lớn (2018). Double 11 năm 2018 dùng tá…
- Meta's Infrastructure Evolution and the Advent of AI Bài tóm tắt · Meta · 2025
…lý fleet: Twine (cluster manager hàng triệu máy), Tectonic (file system), ZippyDB (KV strong consistency), Shard Manager (hàng chục triệu shard), Delos (control plane), Service Rou…
- How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second Bài tóm tắt · WhatsApp · 2014
…thời (giữ tin trong lúc đang chuyển) và các DB Account, Profile, Push, Group. Tin nhắn và media chỉ lưu trong lúc giao; metadata media nằm trong Mnesia in-memory khoảng 2 TB RAM,…
- NVIDIA Dynamo Snapshot: Fast Startup for Inference Workloads on Kubernetes Bài tóm tắt · NVIDIA · 2026
…ạ địa chỉ ảo; host không thấy) và phần CPU (bộ nhớ, thread, file descriptor, namespace). Thay đổi chính - Ghép hai công cụ: cuda-checkpoint đổ trạng thái GPU về bộ nhớ CPU của proc…
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- 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…
- 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…
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- 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:
- Incident 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 incident: 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…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một data…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Hệ thống low latency Chủ đề Thành viên
Ở sàn giao dịch và công ty market making, mỗi giao dịch làm thay đổi thị trường cho giao dịch sau, và ai phản ứng chậm hơn thì thua. Yêu cầu không chỉ là latency trung bình thấp mà latency ổn định ở đuôi, ở thang micro…
- 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".
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn incident bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- 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:
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- 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:
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi read…
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), synchronous call từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…