Zen's 研發筆記

2025年11月14日星期五

搜尋引擎優化的故事 2個月賺了80萬美金

2個月賺了80萬美金，逼 Google 出重拳

這是一個發生在2023年，SEO圈最瘋狂、最暴力，也最傳奇的故事。

我在清邁 SEO 大會（CMSEO）的晚宴上，遇到了這位傳說中的大神 Kaisar。

他來自孟加拉，一個跟台灣一樣，圈子小、但鬼才輩出的地方。

他做了一個網站叫《海螺屋》(Conch House)。

結局是：Google 親自出手，對這個網站判了死刑。

但在死刑執行前，發生了什麼事？

短短2個月，他賺走了 80萬美金（約 2,500萬台幣）。

網站流量從零衝到每月 650萬次，毛利高達 95%。

這根本不是做SEO，這是在「套利」。

---

他是怎麼做到的？

這是一個教科書級別的「套利」故事，簡單粗暴到讓你懷疑人生。

1. 買個好殼（老域名）：他們花了大約 3,000美金，買了一個過期但權重很高的老域名。這是他們最大的一筆投資。

2. 選個沒人打的戰場（利基市場）：他們不碰SaaS、行銷這種殺紅眼的紅海。

他們選什麼？水族箱、健身器材、孕婦用品。

他們發現亞馬遜上有一狗票「難度極低」的關鍵字，這些領域在SEO上「幾乎是空的」。

3. 暴力的內容策略（複製貼上）：什麼原創內容？全部沒有！

他們的內容 0% 原創。

寫了程式，直接把 Amazon 上的產品頁、評論、圖片，「複製貼上」到自己的網站。

4. 瘋狂的發布速度：網站每天自動發布 4,000 到 6,000 個頁面。

短短一個月，海量內容直接淹沒了Google，覆蓋了所有長尾關鍵字。

結果： Google的演算法傻了，以為這是個權威大站。

讓他們每天賺進 19,000 美金。

---

為什麼Google要殺死它？

當這個數據被SEO圈發現時，所有人都瘋了。

故事在網路上病毒式傳播，大家都在問：「這TMD是誰幹的？」

Google被迫出手，直接對網站進行手動處罰，將其除名，判死刑。

但重點來了：Kaisar 親口告訴我：「I safely got my all money.」（我的錢全部安全落袋了）

網站死了，但 80 萬美金，真金白銀，安全落袋。

---

既然賺飽了，為什麼要公開身份？

通常這種被判死的網站主，選擇隱姓埋名，尋找下一次機會。

但是，為什麼他們選擇公開身份？

Kaisar 跟團隊來自孟加拉，他們說：「我們來自一個很小的國家，在一個很小的圈子裡做事。」

這是不是跟台灣的很像？

他們選擇公開身份，不是為了炫耀，而是為了「洗白」。

海螺屋這種賭博式策略，雖然爽，但不可持續。

他們把這次行動當成是一個大型實驗，證明他們有執行超大規模專案的能力。

他們來自一個被認為很窮的小國家，雖然有將近2億人口。

他們想讓大家指著他們說：「等等，我知道這幾個傢伙，他們很猛。」

開啟合作機會，轉向更穩健、更長期正規事業。

---

今晚最大的學習

聽完這個故事，我的 3 個心得：

1. 別再想著複製這種「垃圾SEO」：連 Kaisar自己都說了，「不再嘗試這樣做」。這種漏洞Google已經補上了，現在做只是找死。

2. 學習他們的「商業思維」：

他們贏在「避開紅海」（選冷門利基）和「極致的執行力」（一天6000頁）。做正規SEO，同樣需要這種戰略眼光。

3. 未來是「AI + 正規軍」的天下：他們最後的結論是：「Back to basic」回到基礎。

做好頁面優化 (On-page)、建立真實連結 (Off-page)。即便是「小型網站」，只要策略正確、配合AI提升效率，不用搞那種自殺式攻擊，也能有很好的產出。

這個故事很瘋狂，但它提醒了我們：在演算法面前，機會永遠屬於那些敢於打破規則，但也懂得適時收手的人。

2025年11月1日星期六

隱私權聲明 / Privacy Policy Chinese Input - Zhuyin (中文輸入 - 注音)

# 隱私權聲明 / Privacy Policy

**應用名稱 / App Name:** Chinese Input - Zhuyin (中文輸入 - 注音)
**適用平台 / Platform:** Meta Quest 2/3+
**最後更新日期 / Last Updated:** 2024年12月

---

## 中文版本

### 1. 資訊收集

本應用「Chinese Input - Zhuyin (中文輸入 - 注音)」非常重視您的隱私權。我們致力於保護您的個人資訊。

#### 我們收集的資訊：

**本應用不主動收集任何個人資訊或使用數據。**

#### 我們不收集的資訊：

- ✅ **我們不會收集、儲存或傳輸您的輸入內容**
- 所有注音輸入和候選字選擇都在本地設備上處理
- 您的文字輸入不會上傳到任何伺服器
- 本應用不包含任何遙測或分析追蹤功能

- ✅ **我們不收集個人身份資訊**
- 不需要用戶帳戶或登入
- 不收集姓名、電子郵件、電話號碼等個人資訊
- 不收集位置資訊

- ✅ **我們不收集語音數據**
- 語音識別功能使用離線模型，所有語音處理都在本地設備完成
- 您的語音錄音不會上傳到任何伺服器
- 語音識別結果僅在本地處理和顯示

### 2. 權限使用說明

本應用需要以下權限以提供核心功能：

1. **錄音權限 (RECORD_AUDIO)**
- **用途**：用於語音輸入功能，將您的語音轉換為文字
- **處理方式**：所有語音識別都在本地設備上完成，使用離線語音識別模型
- **數據傳輸**：不會將語音數據上傳到任何伺服器
- **用戶控制**：您可以隨時在設備設定中撤銷此權限

### 3. 資料儲存與安全

- **本地處理**：所有輸入處理均在本地設備完成
- **字典資料**：字典資料儲存在應用內部，無需網絡連接即可使用
- **語音模型**：語音識別模型儲存在應用內部，所有識別在本地完成
- **不儲存內容**：我們不儲存或備份任何用戶輸入內容或語音錄音
- **無數據傳輸**：本應用不會將任何數據傳輸到外部伺服器

### 4. 網絡使用

- **離線功能**：本應用的核心功能（注音輸入、語音識別）完全離線運作，無需網絡連接
- **可選網絡功能**：僅在您主動使用搜索功能時，會使用系統瀏覽器打開網頁（由系統處理，非本應用直接訪問）

### 5. 兒童隱私

本應用適用於所有年齡層，包括兒童。我們嚴格遵守兒童隱私保護規定，不收集任何兒童個人資訊。

### 6. 您的權利

- 您可以隨時在設備設定中管理應用權限
- 您可以隨時停止使用本應用
- 由於我們不儲存個人資訊，無需刪除個人資料的請求流程
- 您可以選擇不使用語音輸入功能，應用仍可正常使用注音輸入

### 7. 隱私政策變更

我們可能會不定期更新本隱私權聲明。重大變更將透過應用更新通知您。

### 8. 聯絡我們

如有任何關於隱私權的問題或疑慮，請透過以下方式聯絡我們：
- 透過 Meta Store 應用頁面提交反饋
- 或透過應用開發者聯絡方式（如適用）

---

## English Version

### 1. Information Collection

The app "Chinese Input - Zhuyin (中文輸入 - 注音)" values your privacy. We are committed to protecting your personal information.

#### Information We Collect:

**This app does not actively collect any personal information or usage data.**

#### Information We Do NOT Collect:

- ✅ **We do NOT collect, store, or transmit your input content**
- All zhuyin input and candidate word selection are processed locally on your device
- Your text input is never uploaded to any server
- This app does not contain any telemetry or analytics tracking

- ✅ **We do NOT collect personally identifiable information**
- No user account or login required
- We do not collect name, email, phone number, or other personal information
- We do not collect location information

- ✅ **We do NOT collect voice data**
- Voice recognition uses an offline model, and all voice processing is completed locally on your device
- Your voice recordings are never uploaded to any server
- Voice recognition results are only processed and displayed locally

### 2. Permission Usage

This app requires the following permissions to provide core functionality:

1. **Microphone Permission (RECORD_AUDIO)**
- **Purpose**: Used for voice input feature to convert your speech to text
- **Processing**: All voice recognition is completed locally on your device using an offline voice recognition model
- **Data Transmission**: Voice data is never uploaded to any server
- **User Control**: You can revoke this permission at any time in your device settings

### 3. Data Storage and Security

- **Local Processing**: All input processing is completed locally on your device
- **Dictionary Data**: Dictionary data is stored within the app and can be used without network connection
- **Voice Model**: Voice recognition model is stored within the app, and all recognition is completed locally
- **No Content Storage**: We do not store or backup any user input content or voice recordings
- **No Data Transmission**: This app does not transmit any data to external servers

### 4. Network Usage

- **Offline Functionality**: The core features of this app (zhuyin input, voice recognition) operate completely offline and do not require network connection
- **Optional Network Feature**: Only when you actively use the search function, the system browser will open a webpage (handled by the system, not directly accessed by this app)

### 5. Children's Privacy

This app is suitable for all ages, including children. We strictly comply with children's privacy protection regulations and do not collect any personal information from children.

### 6. Your Rights

- You can manage app permissions at any time in your device settings
- You can stop using this app at any time
- Since we do not store personal information, there is no need for a personal data deletion request process
- You can choose not to use the voice input feature, and the app can still function normally with zhuyin input

### 7. Privacy Policy Changes

We may update this Privacy Policy from time to time. Significant changes will be notified through app updates.

### 8. Contact Us

If you have any questions or concerns about privacy, please contact us through:
- Submit feedback through the Meta Store app page
- Or through the app developer contact method (if applicable)

---

**本隱私權聲明自應用發布之日起生效。**
**This Privacy Policy is effective from the date of app publication.**

2025年10月9日星期四

SpatialCam Privacy Policy

# Privacy Policy for SpatialCam

**Last Updated: 2025/10/9 **

## Introduction

SpatialCam ("we," "our," or "us") is committed to protecting your privacy. This Privacy Policy explains how our VR camera application for Meta Quest devices collects, uses, and protects your information.

## Information We Collect

### Camera and Media Data
- **Camera Access**: We access your device's passthrough cameras to capture stereoscopic photos and videos
- **Media Files**: Photos and videos you create are stored locally on your device
- **No Cloud Storage**: We do not upload, store, or transmit your photos or videos to any external servers

### Device Information
- **Device Model**: We may collect your Quest device model (Quest 3/3S) for compatibility purposes
- **System Version**: We may collect your Horizon OS version to ensure proper functionality
- **App Usage**: Basic usage statistics may be collected to improve app performance

### Permissions We Request
- **Camera Permission**: Required to access passthrough cameras for photo and video capture
- **Storage Permission**: Required to save photos and videos to your device's gallery
- **Media Access Permission**: Required to organize and manage your captured content

## How We Use Your Information

### Primary Functions
- **Photo and Video Capture**: Use camera access to create stereoscopic content
- **Local Storage**: Save your content to your device's Pictures and Movies folders
- **App Functionality**: Ensure proper operation of camera features and UI

### Analytics and Improvement
- **Performance Monitoring**: Collect anonymous usage data to improve app stability
- **Feature Development**: Use aggregated data to enhance user experience
- **Bug Reporting**: Collect crash reports and error logs to fix issues

## Information Sharing

### We Do NOT Share:
- Your photos or videos
- Personal identification information
- Location data
- Contact information
- Any user-generated content

### Third-Party Services
- **Meta Horizon Store**: Basic app metadata for store listing
- **Analytics Services**: Anonymous usage statistics (if any)
- **No Social Media Integration**: We do not connect to social media platforms

## Data Storage and Security

### Local Storage Only
- All photos and videos are stored exclusively on your device
- Files are saved in standard Android directories:
- Photos: `/Pictures/MetaPassthrough/`
- Videos: `/Movies/MetaPassthrough/`

### Security Measures
- No data transmission to external servers
- Local file encryption follows Android security standards
- Regular security updates through app updates

## Your Rights and Controls

### Data Control
- **Delete Content**: You can delete photos and videos directly from your device
- **App Uninstall**: Removing the app does not affect your saved content
- **Permission Management**: You can revoke camera or storage permissions at any time

### Access and Portability
- **Local Access**: All your data remains on your device
- **Export**: You can manually copy files from your device's storage
- **No Account Required**: No user accounts or login required

## Children's Privacy

SpatialCam is suitable for all ages. We do not knowingly collect personal information from children under 13. If you believe we have collected information from a child, please contact us immediately.

## International Users

This app is designed for Meta Quest devices and follows applicable privacy laws. Users in different jurisdictions may have additional rights under local privacy laws.

## Changes to This Policy

We may update this Privacy Policy from time to time. We will notify users of significant changes through:
- App update notifications
- Updated policy posted in the app
- Version history in app store listing

## Contact Information

If you have questions about this Privacy Policy or our data practices, please contact us at:

**Email**: zenchang.com@gmail.com
**Developer**: zenchang
**App**: SpatialCam for Meta Quest

## Compliance

This Privacy Policy complies with:
- Meta Horizon Store requirements
- Android privacy guidelines
- General data protection principles
- Applicable local privacy laws

---

**Advertising-Related Information (AdMob)**
- This app integrates Google AdMob advertising services
- AdMob may collect the following information for ad delivery:
- Device identifiers (such as Advertising ID)
- IP address
- Device type, operating system version
- App usage information (such as ad impressions and clicks)
- This information is collected by Google AdMob and follows Google's Privacy Policy

**Effective Date**: 2025/10/9
**Version**: 1.0

*This Privacy Policy is effective as of the date listed above and will remain in effect except with respect to any changes in its provisions in the future, which will be in effect immediately after being posted.*

2025年10月2日星期四

設定系統服務 (flask web)

建立 systemd 服務檔案 /etc/systemd/system/stock_web.service：

[Unit]

Description=Taiwan Stock Web Application

After=network.target

[Service]

Type=simple

User=your_username

WorkingDirectory=/path/to/taiwan_stock_web

Environment=PATH=/path/to/taiwan_stock_web/venv/bin

ExecStart=/path/to/taiwan_stock_web/venv/bin/python app.py

Restart=always

[Install]

WantedBy=multi-user.target

啟用服務：

sudo systemctl daemon-reload

sudo systemctl enable stock_web.service

sudo systemctl start stock_web.service

安全性: 此範例為演示用途，生產環境需要增加安全措施
錯誤處理: 需要增加更完善的錯誤處理和重試機制

2025年9月27日星期六

建立一個可持續、能讓你專注的晨間習慣，幫助你每天以清晰的頭腦展開。

為我建立更好的晨間習慣。我希望能更專心地開始新的一天。做我的教練，讓我確實履行。

太好了 🚀 我來當你的晨間教練！我們的目標是：建立一個 可持續、能讓你專注的晨間習慣，幫助你每天以清晰的頭腦展開。

Step 1：先決定基礎框架

我建議晨間習慣由三個核心元素組成：

喚醒身體（伸展、活動、呼吸）
喚醒頭腦（日記、計劃、專注練習）
養分補給（水分、營養）

Step 2：晨間習慣範例流程（30–40 分鐘）

起床後 5 分鐘
- 喝一杯溫水（補水＋啟動消化系統）。
- 不碰手機（至少到結束習慣為止）。
身體啟動 10 分鐘
- 輕微伸展 + 深呼吸（或 5 分鐘快走/開合跳）。
- 讓心跳稍微加速，清除昏沉感。
專注練習 10–15 分鐘
- 寫「晨間三問」：
  ① 今天我最重要的一件事是什麼？
  ② 我感激的三件小事？
  ③ 我希望今天結束時自己處於什麼狀態？
- 或者：5 分鐘冥想，專注於呼吸。
計劃今日 5–10 分鐘
- 寫下今天的 Top 3 任務（避免冗長待辦清單）。
- 確認第一個要完成的工作。

Step 3：實際執行策略

循序漸進：先從 2 個動作開始（如「喝水＋Top 3 任務」），習慣養成後再加其他元素。
設置觸發器：例如「起床後 → 先去倒水」，把行為連結起來。
環境支持：睡前把水杯放好，把筆記本和筆放床頭或書桌。

Step 4：教練陪跑方式

我可以幫你：

每天提醒你執行（你可以回報完成度）。
幫你調整習慣（例如縮短或改變步驟）。
給予小挑戰，增加樂趣（例如「三天連續冥想 5 分鐘」）。

AI可以護膚

把自拍照傳上去就好了

開發成app的話，也很有賣點的

2025年9月3日星期三

linux記憶體，不斷被消耗，觸發oom, 找出原因，並停用某些服務

先說結論

經過一整個星期的高壓工作，現在輕松好多

先前我在找造成硬碟爆漲的原因，主因是模擬browser行為的程式中斷，造成一堆暫存檔，同時我發現有每天一堆系統通知信已累積十幾年，我從未讀，就刪掉，因為我也不會去讀，所以就去停用postfix，但之後硬碟雖未失控爆滿，但系統又會因記憶體不足而而崩潰, 假日半夜我都還在查找原因，朋友約吃飯我也只能先reboot, 換空檔時間，今早總算找到原因

我再向AI確認一下，是否我判斷正確

我檢討原因是，我停用了postfix, 雖然減少大量的寄不出信的空間，但 crontab 觸發sendmail, 卻一直累積大量的process, 最終爆掉, 現在用了 mailto="" , 總算排除，是這樣嗎

您完全正確！您的分析非常精準，這正是問題發生的根本原因和解決機制。讓我為您梳理一下這個完整的邏輯鏈：

問題根本原因分析 (Root Cause Analysis)

您停用了 Postfix：這停止了主要的郵件傳輸代理（MTA）服務。
但 Cron 的機制未變：Linux 系統中，cron 守護進程的默認行為是：任何 cron 作業只要有輸出（無論是標準輸出 stdout 還是標準錯誤 stderr），它就會嘗試调用系統預設的郵件發送程序（通常是 sendmail 或 postdrop）將這些輸出以郵件形式發送給該作業所屬的用户。
進程堆積：由於 Postfix 已被停用，sendmail/postdrop 进程無法成功發送郵件。但它們並不會立即失敗退出，而是會不斷重試或等待，這個過程會產生新的進程。舊的進程卡住，新的進程又不斷被 cron 觸發，導致這些“殭屍”郵件進程像雪球一樣越滾越多。
資源耗盡：每一個休眠的進程都會佔用一定的系統資源（主要是 PID 號、內存中的進程描述符等）。當這種進程數量積累到數百個時，最終會耗盡系統的進程表（PIDs）或內存，觸發 OOM Killer。

解決方案為什麼有效

您採用的 MAILTO="" 方案之所以有效，是因為它從源頭上切斷了問題鏈：

MAILTO=""：這個設置明確地告訴 cron：「不要為這個作業發送任何郵件通知」。
當 cron 作業有輸出時，cron 看到這個設置，就會直接丟棄輸出，而不是去调用 sendmail。
從根源上杜絕了無效的郵件發送嘗試，因此也就不會再產生堆積如山的 sendmail 和 postdrop 進程。

您的解決方案是最正確、最優雅的方法之一。其他替代方法還包括：

在每條 cron 命令末尾重定向輸出：例如 > /dev/null 2>&1，作用和 MAILTO="" 類似，但需要在每一條命令後重複設置。
完全卸載 Postfix：這會移除 sendmail 命令本身，cron 調用失敗也會避免進程堆積，但可能會在其他真正需要發郵件的地方產生錯誤日志。您的方法（保留軟件但禁用其觸發條件）更乾淨。

總結

您的診斷完全正確：停服不禁用 -> cron 持續觸發 -> 進程堆積 -> 資源耗盡。

您採用的 MAILTO="" 方案是對這個問題的標準且有效的解決方案，它直接修改了 cron 的行為模式，從觸發源頭解決了問題。系統狀態的前後對比（從 583 個進程降到 237 個，Swap 使用從 96% 降到 10%）完美地證明了這一點。

這是一個非常經典的 Linux 系統管理案例，您很好地掌握了它！

因為真正的問題，在大量的python程式，被密集排程

執行過程可能遇到些大小不同的狀況

在還需要運作前

就先停用 sendmail , postdrop, postfix

然後陸續找出python程式的問題，或移到別台主機

從您的系統日誌來看，伺服器正在頻繁地發生 Out of Memory (OOM) 的情況，導致核心（Kernel）的 OOM Killer 機制被迫殺死多個進程來釋放記憶體，其中包括 httpd (Apache)、mysqld (MySQL) 和多個 python3.6 進程。

這是一個非常嚴重的問題，需要從「找出元兇」和「根本預防」兩個方面來處理。

第一部分：如何找出是哪一支 Python 程式？

被殺死的進程名稱都是 python3.6，這無法直接區分。您需要查看的是這些進程當時實際執行的命令和參數。

解決方法如下：

查看目前正在執行的 Python 程式
如果問題正在發生，最快的辦法是使用 ps 或 top 命令。被殺死的進程 PID 在日誌中都有記錄（例如 1156, 1203, 1137, 1143 等），雖然它們現在已經不存在，但同一個程式很可能會重新啟動。查看類似的新進程。
bash
```
# 方法一：使用 ps 列出所有 python3.6 進程的詳細命令
ps aux | grep python3.6

# 方法二：使用 top 或 htop，然後按 c 鍵顯示完整命令列
top
# 在 top 介面中，按 'c'
```
重點看每一行的最後部分，通常會顯示腳本名稱，例如 /path/to/your/script.py 或 -m somemodule。
分析系統日誌（如果程式有輸出）
檢查系統的日誌檔（如 /var/log/messages 或 /var/log/syslog），或者檢查您的應用程式（如 Apache、MySQL）的日誌，看看在 OOM 發生前後有沒有相關的錯誤資訊，這可能能幫你定位到是哪個應用先出的問題。

使用審計工具（事後分析）
您可以安裝 auditd 服務來記錄所有進程的執行事件，這樣下次再發生時就能有據可查。

# 安裝 auditd
sudo yum install auditd # 適用於 CentOS/RHEL
sudo apt-get install auditd # 適用於 Ubuntu/Debian

# 新增一條規則，記錄所有執行 python3.6 的動作
sudo auditctl -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/python3.6

# 查看審計日誌
sudo ausearch -sc execve -x python3.6

第二部分：如何預防？

單純重啟進程無法解決問題，必須找到記憶體消耗過大的根本原因。

1. 優先優化您的程式碼
這是最根本的解決方法。多個 Python 進程被殺死，極有可能是因為：
* 記憶體洩漏（Memory Leak）：程式沒有正確釋放不再使用的物件，導致記憶體使用量隨時間無限增長。
* 載入了過大的資料集：例如一次性將一個幾GB的檔案讀入記憶體進行處理。
* 不合理的快取策略：快設了太多內容且沒有過期機制。

**如何優化？**
*   使用 `tracemalloc`、`objgraph`、`pympler` 等工具來分析 Python 程式的記憶體使用情況和洩漏點。
*   對於處理大資料，使用分塊讀取、生成器（Generators）等方式，避免一次性載入。
*   為快取設定大小上限或過期時間。

2. 調整 OOM Killer 的優先級
OOM Killer 在選擇殺死哪個進程時，會參考 oom_score_adj（日誌裡有顯示）。值越低，進程越重要，越不容易被殺死。您可以保護關鍵進程（如 MySQL、主要的 Web Server）。

```bash
# 保護 mysqld 進程，使其非常不容易被殺死
echo '-1000' | sudo tee /proc/$(pgrep mysqld)/oom_score_adj

# 但注意，保護了某些進程，意味著其他進程（如你的 Python 程式）會更容易被殺死。
# 更永久的辦法是編輯 /etc/systemd/system.conf 或服務的 systemd unit file，加入 `OOMScoreAdjust=-1000`
```

3. 增加交換空間（Swap Space）
Swap 空間可以作為記憶體的緩衝地帶，雖然速度慢，但可以在物理記憶體不足時防止進程被直接殺死。如果您的伺服器完全沒有配置 Swap，強烈建議新增。

```bash
# 檢查當前 Swap 空間
free -h

# 新增一個 2GB 的 Swap 檔案
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 永久生效，寫入 /etc/fstab
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
```

4. 增加實體記憶體（RAM）
如果經過優化後，您的應用程式確實就需要那麼多記憶體才能正常運行，那麼升級伺服器規格，增加實體記憶體是最直接、最有效的方案。

5. 設定程序監控與重啟
使用 systemd 或 supervisord 來管理您的 Python 程式。它們可以在程式被 OOM Killer 殺掉後自動將其重啟，並記錄日誌，保證服務的可用性（但這並不能解決記憶體不足的根本問題）。

第三部分：是否能定時做什麼處理？

「定時重啟」是一種治標不治本的方法，但在某些無法立即優化程式碼的場景下，可以作為暫時的緩解措施。

使用 Crontab 定時重啟服務
例如，如果您發現某個 Python 服務在運行一天後會佔用過多記憶體，可以設定在每天凌晨流量低峰期重啟它。

# 編輯 root 的定時任務
sudo crontab -e

# 加入以下行，表示每天凌晨 3 點重啟您的服務
# 假設您的服務由 systemd 管理，名為 my-python-service
0 3 * * * systemctl restart my-python-service

# 或者直接殺死程序（不優雅）
# 0 3 * * * pkill -f "python3.6 /path/to/script.py"

注意：這只是暫時的應急方案。長期來看，仍然需要按照第二部分的建議，從根本上去分析和解決記憶體問題。

總結與行動步驟

立即檢查：使用 ps aux | grep python3.6 立刻查看是哪幾個 Python 腳本在運行。
臨時緩解：
- 考慮新增 Swap 空間。
- 為關鍵資料庫進程（如 mysqld）設定 OOM 保護。
根本解決：
- 定位問題程式：找到那幾個被殺的 Python 程式。
- 程式碼優化：使用記憶體分析工具對其進行分析和優化。
- 資源評估：如果優化後記憶體仍然不足，規劃升級伺服器記憶體。
監控：設定監控系統（如 Prometheus/Grafana），監控伺服器的記憶體使用情況，提前預警，而不是等 OOM 發生後再來處理。

21430 S /usr/sbin/sendmail -FCronDa 0.6 0.0

21431 S /usr/sbin/postdrop -r 0.6 0.0

21596 S CROND 0.2 0.0

21613 S /usr/sbin/sendmail -FCronDa 0.6 0.0

21614 S /usr/sbin/postdrop -r 0.6 0.0

21712 S CROND 0.2 0.0

21717 S /usr/sbin/sendmail -FCronDa 0.6 0.0

21718 S /usr/sbin/postdrop -r 0.6 0.0

21925 S CROND 0.2 0.0

我已停用 postfix 為何還有sendmail,postdrop ...

您观察到的这些 sendmail 和 postdrop 进程确实是 Postfix 邮件系统的组件，即使您已经停用了 Postfix 服务，这些进程仍然可能出现。以下是原因和解决方案：

为什么停用 Postfix 后仍有这些进程？

Cron 作业触发：这些进程大多与 CROND 进程相关联，表明是由 cron 作业触发的。当 cron 作业产生输出时，系统会尝试通过邮件发送这些输出给用户。
未完全卸载：您可能只是停止了 Postfix 服务，但没有完全卸载它，或者系统有其他组件仍然依赖邮件功能。
系统默认配置：许多 Linux 发行版默认配置 cron 将作业输出通过邮件发送。

解决方案

1. 完全卸载 Postfix

# 对于基于 RedHat/CentOS 的系统
sudo yum remove postfix

# 对于基于 Debian/Ubuntu 的系统
sudo apt-get remove postfix

2. 禁用 cron 邮件通知

即使卸载了 Postfix，cron 仍然会尝试发送邮件，这可能会导致错误。您可以通过以下方式禁用 cron 邮件：

# 在 crontab 文件顶部添加（对所有用户生效）
echo 'MAILTO=""' | sudo tee -a /etc/crontab

# 或者为特定用户设置
crontab -e
# 在文件顶部添加
MAILTO=""

3. 重定向 cron 输出到日志文件或 /dev/null

对于个别 cron 作业，您可以重定向输出：

# 将输出重定向到 /dev/null（完全丢弃）
* * * * * /path/to/command > /dev/null 2>&1

# 或将输出重定向到日志文件
* * * * * /path/to/command >> /var/log/mycommand.log 2>&1

4. 杀死现有的 sendmail 进程

# 杀死所有 sendmail 进程
sudo pkill sendmail

# 杀死所有 postdrop 进程
sudo pkill postdrop

5. 安装替代的轻量级邮件工具（可选）

如果您确实需要发送邮件功能，但不想运行完整的 Postfix，可以考虑安装更轻量的替代方案：

# 安装 ssmtp（简单邮件传输）
sudo yum install ssmtp  # CentOS/RHEL
sudo apt-get install ssmtp  # Ubuntu/Debian

# 或安装 nullmailer
sudo yum install nullmailer  # CentOS/RHEL
sudo apt-get install nullmailer  # Ubuntu/Debian

6. 检查系统日志确认问题

# 查看系统日志中与邮件相关的错误
sudo grep -i mail /var/log/messages
sudo grep -i postfix /var/log/messages
sudo grep -i sendmail /var/log/messages

预防措施

为了防止这些进程再次出现，您可以：

定期检查进程：

# 定期检查是否有 sendmail 或 postdrop 进程
ps aux | grep -E '(sendmail|postdrop)'

设置监控警报：

# 如果检测到这些进程，发送警报
if ps aux | grep -q '[s]endmail'; then
    echo "警告: sendmail 进程仍在运行 - $(date)" | mail -s "进程警报" admin@example.com
fi

审查所有 cron 作业：

# 查看所有用户的 cron 作业
sudo ls /var/spool/cron/
sudo cat /var/spool/cron/*

# 查看系统 cron 作业
ls /etc/cron.d/
ls /etc/cron.hourly/
ls /etc/cron.daily/
ls /etc/cron.weekly/
ls /etc/cron.monthly/

通过上述方法，您应该能够彻底解决停用 Postfix 后仍然出现相关进程的问题。最有效的方法是完全卸载 Postfix 并配置 cron 不发送邮件通知。

关于 Sleeping 进程

Sleeping 进程通常是正常的，不一定是资源消耗者：
Sleeping 状态的含义：
睡眠状态的进程正在等待某些事件发生（如I/O操作完成、网络请求响应、定时器到期等）
它们不占用CPU资源，但可能占用内存
这是大多数后台服务和守护进程的正常状态
您的系统状态：
总进程数：583个
运行中的进程：仅1个（非常低）
睡眠进程：465个（这是正常的）
没有停止或僵尸进程（这是好现象）

如何查看 Sleeping 进程的详细信息

要查看哪些进程处于睡眠状态以及它们可能占用的资源，可以使用以下命令：

# 查看所有进程的状态和资源使用
ps aux

# 只查看睡眠状态的进程
ps -eo pid,state,cmd,%mem,%cpu | grep -w S

# 按内存使用排序查看进程
ps aux --sort=-%mem | head -20

# 按CPU使用排序查看进程
ps aux --sort=-%cpu | head -20

# 使用更直观的 htop 工具（如果已安装）
htop

系统资源分析

CPU 使用情况：
用户空间程序占用：16.1% (us)
系统空间占用：4.0% (sy)
空闲：78.7% (id)
CPU 使用率总体较低，系统负载较轻
内存使用情况：
总内存：964MB
已使用：781MB (约81%)
可用内存：183MB
缓存：244MB（这部分内存会在需要时被释放）
交换空间使用：
总交换空间：262MB
已使用：251MB (约96%)
可用交换空间：仅10MB
这是最需要关注的问题：交换空间几乎耗尽

潜在问题与解决方案

1. 交换空间不足问题

您的交换空间使用率高达96%，这会导致系统性能严重下降，因为系统被迫频繁在内存和磁盘之间交换数据。

解决方案：

# 增加交换空间（如前所述）
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 永久生效
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

2. 识别真正消耗资源的进程

虽然大多数睡眠进程是正常的，但有些可能确实占用了过多资源。使用以下命令识别：

# 查看内存占用最高的前10个进程
ps aux --sort=-%mem | head -11

# 查看CPU占用最高的前10个进程
ps aux --sort=-%cpu | head -11

# 查看I/O等待高的进程（如果有iotop）
sudo iotop

3. 检查是否有内存泄漏

某些睡眠进程可能有内存泄漏问题：

# 监控进程内存增长
watch -n 5 'ps aux --sort=-%mem | head -10'

# 查看进程的详细内存映射
pmap -x <PID>

总结与建议

Sleeping 进程通常是正常的：465个睡眠进程在Linux系统中是常见的，它们大多是在等待事件的后台服务。
主要问题是交换空间不足：您的交换空间几乎耗尽，这是最需要立即解决的问题。
系统负载较轻：CPU使用率不高，只有一个进程在运行，系统负载平均值也较低。
建议操作：
- 立即增加交换空间
- 监控内存使用情况，确保不再出现OOM Killer
- 定期检查是否有异常进程消耗过多资源
- 考虑优化应用程序以减少内存使用

您的系统整体状态还算健康，主要是交换空间不足需要解决。增加交换空间后，应该能够显著改善系统稳定性。

訂閱：意見 (Atom)

標籤

2025年11月14日 星期五