middle2

Month: 2020-03

2020-03-02

pm5 11:20:52
@ronnywang 剛才 tainan-sun-500796 11:14 的一個 cronjob 遇到了 "sh: 1: python3: not found"。我看了一下,那個 repo 上次更新是 2/29,應該是 middle2 cronjob 的問題?
這問題我發現在 1/4 開始就會有 2% 左右的 cron 會跑錯容器(因為跑錯容器所以指令失敗),我現在不太確定哪裡有 race condition 造成的 QQ ,我把程式調整了一下再觀察看看
ronnywang 11:32:21
我看看喔
ronnywang 11:34:50
咦,好像有 bug ,那邊應該是別的專案才對,我研究看看
😮 1
yellowsoar 20:34:23
說到 bug … disfactory 用了一個 ORM 的 queue 工具來處理 post method 的 request,處理的時候會把 request 的 image binary 存到 pssql 裡面(這個正在重構當中),可是 2/23 CPU 飆高之後一直到 2/26 都沒辦法正常存取,2/26 透過 ssh tunnel 可以存取 sql (web admin 因為版本太舊無法直接顯示 sql),當時處置是先把 queue list 刪除掉,然後透過 git push -f 和修改 middle2 env 強迫 container 重啟,但兩種方式重啟之後在 queue list 裡面都出現了 2/23-2/26 之間沒出現過的的 queue job,而且這些 job 確定是 2/23-2/26 之間 post 的測試用 request,但當時沒有收到 response。
@ronnywang @cph
不太懂意思,是指說 disfactory 會把 http request queue 起來嗎?
是 queue 在 db 裡面?
yellowsoar 2020-03-02 23:27:49
對,但只有上傳圖片的 request 會 queue 起來,然後由 middle2 上傳到 imgur
yellowsoar 2020-03-02 23:28:34
這狀態神奇到我花了幾天想清楚到底發生了什麼事….
yellowsoar 2020-03-02 23:51:38
還是說禮拜三 vtaiwan & disfactory 遠端同步來重現一下?
yellowsoar 2020-03-04 21:16:01
@ronnywang 我們測試了之後…一切又恢復正常了…
賀(?)
yellowsoar 2020-03-04 21:50:06
但是同樣程式碼的開發環境掛了==

2020-03-04

2020-03-09

wenyi 21:19:03
@ayw255 has joined the channel
wenyi 21:51:16
@ronnywang 想問一下middle2有沒有什麼方法可以不用一直ssh進去也可以讓程式跑,像tmux 或 nohup 的functionality。例如現在0archive要完整抓ptt需要四五天以上,目前是讓電腦一直開著保持ssh連線才不會斷掉
yellowsoar 2020-03-10 13:07:30
技術上 ssh over http 應該辦得到?但 PaaS 還真的不是設計來這樣用的@@

2020-03-10

ronnywang 12:04:53
middle2 在設計上是 PaaS ,這樣的需求有點脫離 PaaS 的範圍了,原先設計 ssh 進去主要是方便了解環境 debug 用,進來裡面常態執行程式不太算是原先設計的用法了 XD
ronnywang 12:06:21
如果要 workaround 的話,繼續這樣使用的話,我覺得可能比較理想的作法是 middle2 還是不改任何東西,但是再找一台跳板主機專門負責 ssh + tmux
摁好,瞭解了!那我先找其他平台跑好了!不增加middle2的負擔

2020-03-11

2020-03-17

pm5 12:25:14
disinfo mysql 有一個 alter table 看來佔用太多記憶體了。我來把它砍掉⋯⋯

2020-03-19

ronnywang 14:00:42
@pm5 我看到你好像有在用 worker 功能了?目前我 worker 的設計是每一分鐘他會檢查該程式是否有在跑,如果發現沒在跑就會重跑
pm5 14:04:45
試用了一下,但那是只要跑一次的程式,我又不確定它什麼時候會被跑完,所以就換別的方法了

2020-03-23

pm5 10:30:50
@ronnywang 我觀察到一個容易出現 "Error: No such container: c-2" 錯誤訊息的 cronjob 情況,是 job 特別短的時候,例如在 ~3 secs 以內結束的話。最近 0archive 的 update job 有點 process management 的問題,程式執行以後,以為有另一個 process 還沒結束,所以程式就不執行工作馬上結束。這種情況下多次以後似乎蠻容易遇到 No such container。之前 @fockerlee 常遇到這個問題的 container,有些也是執行一個 ls 指令就結束的 cronjob。
ronnywang 10:32:04
問一下,有沒有可能有個情況,就是執行的 script 他會在背景執行,所以一執行指令就被我判定為跑完(但其實是在背景跑)
pm5 10:32:10
就容易發生 race condition 的狀況?也許我可以在 cronjob 加個 sleep 10 延長它結束的時間才暫時避免這個問題
ronnywang 10:32:15
結果就是緊接著 middle2 想把跑完的資源釋放掉
ronnywang 10:32:50
有 fork 但是沒有 wait 的情況
pm5 10:34:22
早上回報的那個 `ns update` 的指令是不會在背景執行的,它用的 twisted 的平行處理是跟 nodejs 一樣的 event loop 模式,所以沒有 fork。之前 fb scaper 倒是可能有這種情況
pm5 10:35:13
嗯⋯⋯也許是有。selenium 是 fork 的樣子。
pm5 10:36:38
它們都有用 selenium。selenium quit 在 docker 環境裡之前測試會遇到沒有 wait(留下 zombie process)的情況
ronnywang 10:37:50
我看記錄 no container 是發生在 shutdown 不是發生在執行時,執行可能是有順利執行完的
ronnywang 10:38:11
我這邊增加 shutdown 前 sleep (2) 試試看好了
🖖 1
ronnywang 10:39:04
確實有可能像你說的,當執行太短時,docker exec xxx ===(秒殺) ===> docker shutdown (docker 噴 No such container )
pm5 10:39:31
但 update 如果只跑了 <1s 那就是它以為有其它 process 在跑,所以馬上結束。這個情況下不會啟動 selenium,所以沒有上面講的沒有 wait 的問題。看起來還是秒殺的問題比較有可能。
ronnywang 22:36:48
在找這問題過程有發現 middle2 一個 cron 的 race condition bug (race condition 超難 debug orz)
大概情況如下:
有兩隻不同的 script
一隻是每分鐘運作一次,他會檢查有沒有哪個 wait node 超過 60 分鐘沒人用把他 free 掉,或是發現有 node 程式碼已經更新,就會標為 over 之後把他釋放掉,不讓他再被使用
另一隻是負責處理 CronJob 的,當某隻 cron 需要被跑時,他會找一個 狀態是 wait 的 node 來執行(而且程式碼要是最新的)

不過可能是因為 cache 的關係, cronjob 那邊沒發現 node 的程式已經更新了,所以拿了過時的 node 來執行 cronjob, 造成該被 free 掉的 node 因為持續有在跑東西結果一直沒被 free ,而且有時會剛好同時做 shutdown 跟執行 cronjob 造成可能的 No Container 的情況