thắc mắc Phân biệt giữa Junior và Senior?

  • Người tạo chủ đề Người tạo chủ đề girlxinhgai
  • Ngày bắt đầu Ngày bắt đầu
Như đi học môn OS có đề cập tới Deadlock Prevention. Như vậy vẫn cod thể xây dựng 1 hệ điều hành đểngawn không xảy ra deadlock nhỉ? (tất nhiên là sẽ tradeoff)

Tôi đồng ý với anh là OS cung cấp giải pháp ngăn panic bằng cách detect deadlock. Nhưng trong docs của microsoft nó nói rõ ràng là expose ra tasks trace để check. Hơn nữa 1 task waiting và consume nhiều cpu thì nó hiển thị qua ví dụ top (tôi ko rành trên windows cmd check thế nào) chứ đâu phải tất cả các task đều giống nhau?
Môn hệ điều hành là môn chung, nó là model cho bất cứ úng dụng nào, ko có cách nào OS có thể ngăn không cho xãy ra deadlock, nó là nội tại của ứng dụng, việc của OS là phát hiện và ngăn chặn panic như tôi đã nói trước đó. Tại sao các OS trước đây 1 ứng dụng bị treo làm treo luôn OS mà windows cao cấp sau này ko bị, hoặc thậm chí unix khi ứng dụng bi deadlock dump memory thì cũng ko sập hệ thống? đó là do os nó phát hiện và ngăn chặn. Os unix có rất nhiều tham số , ví dụ max thread open ngăn ko cho mở quá nhiểu thead. rồi còn có cơ chế prevent fork bomd khi gặp mấy cái ứng dụng model muti process open vô tội vạ. Toàn bộ những cơ chế đó là ngăn ko cho ứng dụng deadlock vượt rào.
https://www.cyberciti.biz/tips/linux-limiting-user-process.html
 
Tôi đúng là có google HAproxy để đọc thêm. Còn mấy cái ở trên là dựa trên lý thuyết OS. Đúng là tôi chưa xử lý deadlock nhiều sâu đến OS level nên có thể không bằng anh.

Tôi có 1 ý là nếunhuw tình huống deadlock xảy ra anh cũng có traffic log hoặc snapshot của hệ thống. Hơn nữa nếu là nếu anh bring 1 cái hệ thống khác tương tự lên chạy với cái live traffic thì nó phải xảy ra deadlock lại chứ?

Tôi hỏi để hiểu thêm chứ không phải nói anh sai. Vì lí thuyết tôi mang ra áp dụng có thể áp dụng sai
Tôi chỉ nói phạm vị 1 ứng dụng mutithread thôi. Hệ thống đang chạy bình thường, 1 thời điểm ra vào nhiêu tác vụ thao tác. Là người quản trị bình thường vài một ngày được thông báo là thao tác gì đó không duoc. Vào kiểm tra hệ thống thấy ứng dụng bị ngõm, dmesg báo lỗi kill process . Lúc đó log của phần mềm ghi ra hoàn toàn ko có tác dụng tìm lỗi. Giả sử kêu Kh giả lập lại cũng ko thấy nó ngõm ? Vậy nguyên nhân ko phải logic bug thông thường. Nếu nó vẫn lâu lâu bị thì người quản trị hệ thống phải bật như bên dưới. Nếu java thì cũng có luôn. Bật cái này dĩ nhiên hiệu năng se giảm vì ghi ra file liên tục tương ứng với bộ nhớ ứng dụng
https://stackoverflow.com/questions...-dump-for-already-running-processes-in-redhat
Sau 1 thời gian bật coredump thì 1 ngày dep trời ứng dụng lăn ra chết. Vậy lúc đó tôi chỉ việc mang cái file dump này, nếu là linux C hay C++ thì GDB. Mở lên và debug, dĩ nhiên là vẫn có thể dùng strace để tìm nếu ngồi 24/7 monitor. Đưa java dump hay coredump cho developer. Đó chính là quy trình.
 
chủ thớt thông minh vl, trước khi đi pv lên voz bait một phát là có ngay 1 đống anh tài vào, lấy được mớ thông tin ôn luyện.
Nhớ có topic gì trên reddit nói là khi đặt câu hỏi trên stackoverflow thì nên log acc clone vào trả lời bậy bạ, thì tức khắc có đứa nhảy vào chỉnh bạn ngày và cho câu trả lời đúng, đơn giản vì họ muốn chứng minh là mình đúng :LOL:
muốn có câu trả lời chính xác trên mạng thì hãy post 1 câu trả lời sai :shame:
 
Tôi chỉ nói phạm vị 1 ứng dụng mutithread thôi. Hệ thống đang chạy bình thường, 1 thời điểm ra vào nhiêu tác vụ thao tác. Là người quản trị bình thường vài một ngày được thông báo là thao tác gì đó không duoc. Vào kiểm tra hệ thống thấy ứng dụng bị ngõm, dmesg báo lỗi kill process . Lúc đó log của phần mềm ghi ra hoàn toàn ko có tác dụng tìm lỗi. Giả sử kêu Kh giả lập lại cũng ko thấy nó ngõm ? Vậy nguyên nhân ko phải logic bug thông thường. Nếu nó vẫn lâu lâu bị thì người quản trị hệ thống phải bật như bên dưới. Nếu java thì cũng có luôn. Bật cái này dĩ nhiên hiệu năng se giảm vì ghi ra file liên tục tương ứng với bộ nhớ ứng dụng
https://stackoverflow.com/questions...-dump-for-already-running-processes-in-redhat
Sau 1 thời gian bật coredump thì 1 ngày dep trời ứng dụng lăn ra chết. Vậy lúc đó tôi chỉ việc mang cái file dump này, nếu là linux C hay C++ thì GDB. Mở lên và debug, dĩ nhiên là vẫn có thể dùng strace để tìm nếu ngồi 24/7 monitor. Đưa java dump hay coredump cho developer. Đó chính là quy trình.
OK cảm ơn anh hôm nay tôi học được thêm xử lý deadlock thực tế. Nhưng mà bình thường chắc team DevOps họ xử lý mấy tầng dưới chắc tôi không có permission (không biết có chạy đc dmesg không nữa)
Với lại giả sử tôi dùng k8s, nếu app ngỏm thì liveness check die nó tự động restart server thì không kịp xem dmesg. Có cách nào xử lý không? Hay là nếu thấy liveness check die liên tục thì bật coredump lên rồi write ra file sau đó save lại trước khi restart?
 
OK cảm ơn anh hôm nay tôi học được thêm xử lý deadlock thực tế. Nhưng mà bình thường chắc team DevOps họ xử lý mấy tầng dưới chắc tôi không có permission (không biết có chạy đc dmesg không nữa)
Với lại giả sử tôi dùng k8s, nếu app ngỏm thì liveness check die nó tự động restart server thì không kịp xem dmesg. Có cách nào xử lý không? Hay là nếu thấy liveness check die liên tục thì bật coredump lên rồi write ra file sau đó save lại trước khi restart?
Ứng dụng level thấp như C, C++ hay Java mới có dump memory để xử lí deadlock, các ứng dụng cấp cao ví dụ như nodejs sẽ có cơ chế tìm deadlock dựa trên tool của nó, golang cũng vậy, search dùng ngôn ngử nào thì có tool của thằng đó. Mấy thằng cấp cao dạng thông dịch, deadlock control bởi engine của nó. Và ko phải lúc nào ngõm củng là deadlock .
 
cái Deadlock thì mình hơi ngáo, ko hiểu gì luôn, mà học đúng môn Assembly 8086 của ông thầy hồi đó học BK, ổng nói môn đó ổng gần Max điểm, kinh thật, giờ nhớ tới cái môn này là sợ vl
20218cdf5f09-d679-4b82-9966-f9186028d873.png
 
cái Deadlock thì mình hơi ngáo, ko hiểu gì luôn, mà học đúng môn Assembly 8086 của ông thầy hồi đó học BK, ổng nói môn đó ổng gần Max điểm, kinh thật, giờ nhớ tới cái môn này là sợ vl
20218cdf5f09-d679-4b82-9966-f9186028d873.png
mấy cái mutithread mới dễ deadlock và khó tìm, chứ mấy cái đơn luồng, muti proces thì ko phức tạp. Ví dụ abba deadlock là kiểu phức tạp trên ứng dụng mutithread
https://www.oreilly.com/library/vie...75/edf57b67-a572-4202-8e56-18c85c2141e4.xhtml
 
ê sẵng công ty tôi đang tuyển. Thớt muốn nhảy việc không? 3 round(Sin, Ấn) + 1 round HR.
 
ê sẵng công ty tôi đang tuyển. Thớt muốn nhảy việc không? 3 round(Sin, Ấn) + 1 round HR.
Năm ngoái công ty tăng lương nhiều, năm nay tăng ít, lí do là năm ngoái SE bị gom nhiều quá tăng giá. Năm nay gom giãm lại nên tăng ít. Thật là đáng buồn. Mà dạo này thấy toàn tuyền DevOps nhỉ. SE ế mèm
 
Năm ngoái công ty tăng lương nhiều, năm nay tăng ít, lí do là năm ngoái SE bị gom nhiều quá tăng giá. Năm nay gom giãm lại nên tăng ít. Thật là đáng buồn. Mà dạo này thấy toàn tuyền DevOps nhỉ. SE ế mèm
Thì kiếm người làm DevOps khó mà. Như tôi làm SE lâu lâu chỉ đụng đến mà học toàn lý thuyết thôi chứ thực tế không đụng nhiều nên áp dụng không được :beat_brick:

Như thím hiểu sâu về OS vậy là đang làm DevOps à?
 
Năm ngoái công ty tăng lương nhiều, năm nay tăng ít, lí do là năm ngoái SE bị gom nhiều quá tăng giá. Năm nay gom giãm lại nên tăng ít. Thật là đáng buồn. Mà dạo này thấy toàn tuyền DevOps nhỉ. SE ế mèm
Những năm trước có năm mơ cũng chưa thấy lương 3k cho dev ở Việt Nam. Hoặc là lúc đó có rồi nhưng chưa dám nghỉ tới. Năm nay dịch, mở màn cho trào lưu mới "remote" -> senior java backend toàn up to 5k. Riêng kèo Binance 6k dev ở VIệt Nam là có thật người thật việc thật.
1632146935213.png
1632146964727.png
1632146988740.png
1632147022449.png
1632147049198.png
1632147091087.png
 
Thì kiếm người làm DevOps khó mà. Như tôi làm SE lâu lâu chỉ đụng đến mà học toàn lý thuyết thôi chứ thực tế không đụng nhiều nên áp dụng không được :beat_brick:

Như thím hiểu sâu về OS vậy là đang làm DevOps à?
Ko biết gọi là gì nữa. Ngoài job chính ở công ty là ôm đám trên aws (server, cloudfront, lb, cache, mysql ) và đám máy chủ ở QTSC thì Job riêng ôm đống router/switch trên IDC, cục storage ceph, openstack, mấy cục vmware, mấy con firewall chống ddos. Nói chung đủ món.
 
Thì kiếm người làm DevOps khó mà. Như tôi làm SE lâu lâu chỉ đụng đến mà học toàn lý thuyết thôi chứ thực tế không đụng nhiều nên áp dụng không được :beat_brick:

Như thím hiểu sâu về OS vậy là đang làm DevOps à?
ko hẳn khó đâu ráng tim mấy cái job build lúc đầu ấy. vừa system design, vừa contribute cho mấy cái solution chọn lựa công nghệ. Rồi làm mấy task devops, tớ cũng đang làm mấy này, được thêm client kêu làm IaC nên biết thêm terraform nữa.
 
Ko biết gọi là gì nữa. Ngoài job chính ở công ty là ôm đám trên aws (server, cloudfront, lb, cache, mysql ) và đám máy chủ ở QTSC thì Job riêng ôm đống router/switch trên IDC, cục storage ceph, openstack, mấy cục vmware, mấy con firewall chống ddos. Nói chung đủ món.
Nghe bác nói giống system engineer :D
 
Nghe bác nói giống system engineer :D
Uh title là bên SE, không làm việc với develop nhiều. Chủ yếu làm việc đối tác nước ngoài. Có dự án thì deploy hệ thống, tích hợp, model. Làm gì làm miễn sao dự án chạy trong suốt vòng đời,đừng để vấn đề gì liên quan tới hệ thống.
 

Thống kê chủ đề

Ngày tạo
girlxinhgai,
Người trả lời cuối
darkrose,
Trả lời
279
Lượt xem
37.924
Quay lại
Lên đầu trang