Điều tra ổ cứng

Điều tra ổ cứng

Tin ngắn hàng ngày dành cho bạn
  • MongoDB cũng áp dụng Eating Our Own Dog Food vào trong quy trình phát triển sản phẩm của họ. Nếu còn chưa biết đó là gì thì bạn hãy đọc thêm bài viết Eating your own dog food - Dùng sản phẩm của chính mình.

    » Xem thêm
  • swapy là một thư viện giúp bạn tạo ra thao tác kéo thả để hoán đổi vị trí của các thành phần một cách dễ dàng.

    Thư viện hỗ trợ rất nhiều nền tảng, rất thích hợp để xây dựng một cái gì đó mang tính cá nhân hoá như trang Dashboard của người dùng.

    » Xem thêm
  • Ui! Blog đang dính một lỗi bảo mật khá nghiêm trọng. Không biết có bạn nào phát hiện ra chưa. Dù chưa ảnh hưởng đến người dùng nhưng thông qua quá trình Eating your own dog food thì mới phát hiện ra á. Để sửa xong thì mình kể chi tiết.

    » Xem thêm

Vấn đề

Xin chào các độc giả, thành thật xin lỗi vì hơn một tuần vừa qua tôi không viết thêm bài mới nào. Như đã chia sẻ trong Threads, tuần vừa rồi tôi khá bận rộn với dự án ở trên Công ty, tối về nhà chỉ kịp cập nhật thêm một ít thông tin trong ngày là lại đi nằm để nghe tiếp cuốn sách đang dang dở. Đó là cuốn "Suối nguồn" - kể về câu chuyện xoay xung quanh một kiến trúc sư trẻ tuổi bị đuổi học vì anh... có những ý tưởng vượt trước thời đại. Chà, kiến trúc sư & lập trình viên đâu có liên quan đâu nhỉ? Ấy thế mà câu chuyện càng ngày càng hấp dẫn đến mức không thể dứt ra được. Và như bạn thấy đây, đây là một bài viết chuộc lỗi.

Tuần trước tôi phải gỡ một lỗi kỳ lạ ở phía máy chủ. Một anh bạn ở đội phát triển ứng dụng di động báo rằng anh không thể thực hiện một cuộc gọi API đến máy chủ development (dev). Sau khi ngồi cùng nhau gỡ lỗi thì chúng tôi phát hiện ra: cùng một API đó nhưng nếu gọi với một ít dữ liệu truyền lên thì được. Ngược lại, khi cố gắng gửi lên một lượng lớn dữ liệu thì ngay lập tức nhận được phản hồi lỗi 500 từ máy chủ, lỗi đó được phản hồi từ nginx.

Sau đó tôi kiểm tra nhật ký (logs) của nginx thì thấy một lỗi trông như thế này:

[crit] 1530375#1530375: *11347 pwrite() "/var/lib/nginx/body/0000000020" failed (28: No space left on device), client: ****, server: ****, request: "POST **** HTTP/2.0", host: "****"

Không còn nghi ngờ gì nữa, ổ cứng đã hết. Nhiều người có thể thắc mắc tại sao ổ cứng hết mà không ai biết thì đây là một máy chủ già cỗi nằm ở trên GCP, nó không thể cài được công cụ theo dõi hệ thống nên phải đợi đến khi có lỗi thì mới biết.

Ngay sau đó, tôi đã truy tìm xem thủ phạm gây đầy ổ cứng là gì, vì máy chủ này vốn dĩ không có nhiều thứ và nó chỉ phục vụ cho mục đích phát triển nội bộ.

Điều tra

Điều đầu tiên mà tôi nghĩ đến là các tệp tin logs, các tệp này qua năm tháng sẽ "dày" lên rất nhanh và đó hẳn là nguyên nhân gây ra tình trạng đầy ổ cứng nhanh nhất. Nhưng sau khi vào thư mục logs của nginx, tôi nhận ra đây không phải là vấn đề vì các tệp này vốn dĩ rất nhỏ, không thể làm đầy ổ cứng nhanh như thế. Chà! 🤔 chắc phải điều tra ở quy mô lớn.

Đầu tiên hãy xem tình trạng thực tế của ổ cứng bằng lệnh df -h, một cái gì đó đập vào mặt giống như tình trạng ổ cứng đang ở trạng thái 100% dưới đây.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       9.6G  9.6G  0G  100% /
devtmpfs        2.0G     0  2.0G   0% /dev
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           394M   41M  354M  11% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
...

Đúng là hết ổ cứng rồi, vậy thì bộ nhớ đang phân bổ ở những đâu? Hãy quay ra thư mục gốc và kiểm tra bằng lệnh du -sh */.

$ cd /
$ du -sh */
160M	bin/
159M	boot/
0	    dev/
5.0M	etc/
545M	home/
...

Hơi lộn xộn nhỉ, hãy sắp xếp lại kết quả giảm dần cho dễ nhìn.

$ du -sh */ | sort -hr
4.8G	var/
2.3G	snap/
988M	lib/
545M	home/
529M	usr/

Vậy là đã rõ, thư mục var đang làm cái quái gì đó mà giữ gần 5GB ổ cứng trong khi tổng dung lượng chưa đến 10GB. Tiếp tục lặp lại các bước trên khi di chuyển vào trong thư mục var, tôi phát hiện ra một thư mục có tên là cache chiếm gần một nửa trong số 4.8GB đó. Sau khi xác nhận đó chỉ là bộ nhớ tạm, tôi có thể yên tâm xoá nó và giải phóng 2GB bộ nhớ cho máy chủ già cỗi của mình.

Đến đây mọi chuyện gần như là giải quyết xong. Nhưng hãy nhìn lại các bước làm của mình đang mất khá nhiều thời gian và thủ công. Trong môi trường máy chủ, chúng ta dùng lệnh là chủ yếu, nhưng hãy nghĩ về lúc dùng một hệ điều hành nào đó như là Windows, có thể duyệt qua các ổ đĩa, các thư mục trong đó để xem chúng có gì và xoá đi những tệp tin thừa thãi. Trong môi trường dòng lệnh có cách nào làm được như thế không?

Công cụ phân tích ổ cứng

Sau một hồi mày mò tìm kiếm thì tôi phát hiện ra một công cụ có tên là ncdu - giúp phân tích ổ cứng và hỗ trợ duyệt qua lại thư mục để xem toàn bộ dữ liệu có trong đó. ncdu hỗ trợ nhiều hệ điều hành, trong đó có cả Ubuntu. Dự án này là mã nguồn mở.

$ sudo apt install ncdu

Cách dùng rất đơn giản, sau khi cài đặt, di chuyển ra thư mục gốc và chạy một lệnh để ncdu thu thập dữ liệu ổ cứng.

$ cd /
$ ncdu -o ~/report.ncdu

Đợi một lúc một tệp báo cáo được tạo ra. Sau đó tiến hành xem bằng cách mở báo cáo.

$ ncdu -f ~/report.ncdu

Ngay lập tức bạn sẽ nhìn thấy một giao diện trực quan về bộ nhớ đang phân bổ ở đâu, sử dụng các phím mũi tên để duyệt qua lại các thư mục. Lúc này có khác gì trên Windows đâu chứ, và chúng ta có thể dễ dàng xem tình trạng ổ cứng của mình đang như thế nào.

NCDU

Còn một điều nữa mà cá nhân tôi thấy hữu ích là với những người dùng MacOS, mỗi lần kiểm tra bộ nhớ trong Cài đặt có cảm thấy "nóng mặt" khi xem mục "System Data" ăn hết một nửa dung lượng ổ cứng mà không biết nó là gì hoặc muốn xoá ở đâu không? Hãy thử dùng ncdu và có nhiều điều bất ngờ xảy ra đấy 🫣

MacOS System Data

Cao cấp
Hello

Tôi & khao khát "chơi chữ"

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (0)

Nội dung bình luận...