507 Insufficient Storage 错误的原因和解决方案|磁盘容量·S3·云环境
分类:服务器·基础设施
本文目前仅提供日文版本。我们正在进行翻译工作。
在文件上传或大量数据写入处理过程中,可能会发生「507 Insufficient Storage」错误。该错误表示服务器缺少处理请求所需的存储容量。本文从 507 错误的发生原因、磁盘容量检查方法、日志膨胀对策、云存储容量管理以及监控设置等方面进行系统解读。
什么是 507 错误
HTTP 507 Insufficient Storage 是 RFC 4918(WebDAV 扩展)中定义的状态码。当服务器无法分配完成请求所需的存储空间时返回。它最初是 WebDAV 协议的状态码,现在也被用作文件存储相关问题的通用错误。
此错误通常是临时状态异常,可以通过释放磁盘空间来解决。但是,如果不处理,可能会导致严重的故障,如数据库写入失败、日志输出停止和应用程序崩溃。
| 相关状态 | 名称 | 区别 |
|---|---|---|
| 413 | Content Too Large | 请求大小超过配置的上限(与服务器容量无关) |
| 507 | Insufficient Storage | 服务器的物理/逻辑存储容量不足 |
| 503 | Service Unavailable | 临时服务中断(可能由容量不足引起) |
服务器磁盘容量的检查方法
当发生 507 错误时,首先检查服务器的磁盘容量。使用以下命令来确定磁盘空间在哪里被消耗。
# ファイルシステムごとの使用量を確認
df -h
# 出力例:
# Filesystem Size Used Avail Use% Mounted on
# /dev/sda1 50G 47G 3.0G 94% /
# /dev/sdb1 200G 180G 20G 90% /data
# 特定ディレクトリの使用量を確認
du -sh /var/log/
du -sh /var/www/
du -sh /tmp/
# サブディレクトリごとの使用量をソートして表示
du -h --max-depth=1 /var/ | sort -rh | head -20
# inode(ファイル数)の使用状況も確認(容量はあるのにファイルが作れない場合)
df -i
# 大きなファイルを探す(100MB以上)
find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -20
# 最近24時間以内に更新された大きなファイルを探す
find /var -type f -mtime -1 -size +50M -ls 2>/dev/null
日志文件大小管理(logrotate)
磁盘空间不足的最常见原因之一是日志文件膨胀。访问日志、错误日志和应用程序日志膨胀到数 GB 的情况并不罕见。正确配置 Linux 的 <code>logrotate</code> 以执行自动日志轮转。
# /etc/logrotate.d/nginx の設定例
/var/log/nginx/*.log {
daily # 毎日ローテーション
missingok # ログファイルが無くてもエラーにしない
rotate 14 # 14世代分を保持
compress # gzip で圧縮
delaycompress # 直近1世代は圧縮しない
notifempty # 空のログはローテーションしない
create 0640 www-data adm # 新しいログファイルの権限
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
endscript
}
# /etc/logrotate.d/app の設定例(アプリケーションログ)
/var/www/app/storage/logs/*.log {
daily
missingok
rotate 7 # 7日分を保持
compress
delaycompress
notifempty
create 0644 www-data www-data
maxsize 100M # 100MB を超えたら日次以外でもローテーション
dateext # 日付をファイル名に付与
dateformat -%Y%m%d
}
# 手動でローテーションを実行(テスト)
sudo logrotate -f /etc/logrotate.d/app
# ドライラン(実行せずに結果を確認)
sudo logrotate -d /etc/logrotate.d/app
# ログのサイズを即座に確認
ls -lhS /var/log/nginx/ | head -10
ls -lhS /var/www/app/storage/logs/ | head -10
清理 tmp 目录
文件上传时生成的临时文件、会话文件、缓存文件频繁地在 <code>/tmp</code> 目录中积累,占用磁盘空间。
# /tmp の使用量を確認
du -sh /tmp/
# 古い一時ファイルの確認(7日以上前)
find /tmp -type f -mtime +7 -ls | head -20
# 古い一時ファイルを削除(7日以上前のファイル)
find /tmp -type f -mtime +7 -delete
# PHPセッションファイルの確認と掃除
du -sh /var/lib/php/sessions/
find /var/lib/php/sessions/ -type f -mtime +1 -delete
# PHPのアップロード一時ファイルが残っていないか確認
ls -la /tmp/php*
# systemd-tmpfiles を使った自動掃除(systemd環境)
# /etc/tmpfiles.d/cleanup.conf に以下を追加:
# d /tmp 1777 root root 7d
# 上記設定は /tmp 内の7日以上前のファイルを自動削除
# cron で定期的に掃除するスクリプト例
# /etc/cron.daily/cleanup-tmp
#!/bin/bash
# 7日以上前のtmpファイルを削除
find /tmp -type f -mtime +7 -delete 2>/dev/null
# アプリケーションのキャッシュを掃除
find /var/www/app/storage/framework/cache -type f -mtime +3 -delete 2>/dev/null
# 容量を記録
echo "$(date '+%Y-%m-%d %H:%M:%S') - $(df -h / | tail -1)" >> /var/log/disk-usage.log
S3 和云存储的容量限制
即使使用云存储,也需要注意容量限制和成本。虽然AWS S3本身没有存储桶容量限制,但必须正确配置成本管理和生命周期策略。
# AWS CLI で S3 バケットのサイズを確認
aws s3 ls s3://my-bucket --recursive --summarize --human-readable | tail -2
# 出力例:
# Total Objects: 152345
# Total Size: 85.3 GiB
# CloudWatch メトリクスでバケットサイズを確認
aws cloudwatch get-metric-statistics \
--namespace AWS/S3 \
--metric-name BucketSizeBytes \
--dimensions Name=BucketName,Value=my-bucket Name=StorageType,Value=StandardStorage \
--start-time 2026-04-13T00:00:00Z \
--end-time 2026-04-14T00:00:00Z \
--period 86400 \
--statistics Average
// S3 ライフサイクルポリシーの設定例
// 古いファイルを自動的にアーカイブ・削除
{
"Rules": [
{
"ID": "archive-old-uploads",
"Status": "Enabled",
"Filter": {
"Prefix": "uploads/"
},
"Transitions": [
{
"Days": 90,
"StorageClass": "STANDARD_IA"
},
{
"Days": 365,
"StorageClass": "GLACIER"
}
]
},
{
"ID": "delete-temp-files",
"Status": "Enabled",
"Filter": {
"Prefix": "tmp/"
},
"Expiration": {
"Days": 7
}
},
{
"ID": "cleanup-incomplete-uploads",
"Status": "Enabled",
"Filter": {
"Prefix": ""
},
"AbortIncompleteMultipartUpload": {
"DaysAfterInitiation": 3
}
}
]
}
| 云服务 | 容量限制 | 每个文件限制 | 注意事项 |
|---|---|---|---|
| AWS S3 | 无限制 | 5TB | 成本管理和生命周期策略配置很重要 |
| Google Cloud Storage | 无限制 | 5TB | 启用对象版本控制时需要注意成本增加 |
| Azure Blob Storage | 无限制 | 约 4.75TB (Block Blob) | 按账户的带宽和IOPS限制 |
| DigitalOcean Spaces | 250GB(取决于计划) | 5GB | 注意您的计划容量限制 |
监控配置(阈值告警)
对于 507 错误,预防最为重要。设置监控,当磁盘使用率超过一定阈值时发出警报。
#!/bin/bash
# /usr/local/bin/disk-alert.sh
# ディスク使用率監視スクリプト
THRESHOLD=80 # 警告しきい値(%)
CRITICAL=90 # 危険しきい値(%)
MAILTO="admin@example.com"
df -h --output=pcent,target | tail -n +2 | while read usage mount; do
# パーセント記号を除去
usage_num=$(echo "$usage" | tr -d '%')
if [ "$usage_num" -ge "$CRITICAL" ]; then
echo "CRITICAL: ${mount} のディスク使用率が ${usage}% です" | \
mail -s "[CRITICAL] ディスク容量警告 - $(hostname)" "$MAILTO"
elif [ "$usage_num" -ge "$THRESHOLD" ]; then
echo "WARNING: ${mount} のディスク使用率が ${usage}% です" | \
mail -s "[WARNING] ディスク容量警告 - $(hostname)" "$MAILTO"
fi
done
# crontab に登録(5分ごとに実行)
# */5 * * * * /usr/local/bin/disk-alert.sh
# Prometheus + node_exporter でのアラート設定例
# /etc/prometheus/alerts/disk.yml
groups:
- name: disk_alerts
rules:
- alert: DiskSpaceWarning
expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "ディスク使用率が80%を超えています"
description: "{{ $labels.instance }} の {{ $labels.mountpoint }} の使用率が {{ $value }}% です。"
- alert: DiskSpaceCritical
expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 90
for: 2m
labels:
severity: critical
annotations:
summary: "ディスク使用率が90%を超えています - 即時対応が必要"
description: "{{ $labels.instance }} の {{ $labels.mountpoint }} の使用率が {{ $value }}% です。"
- alert: DiskInodeWarning
expr: (1 - node_filesystem_files_free / node_filesystem_files) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "inode使用率が80%を超えています"
# Python での簡易ディスク監視スクリプト
import shutil
import smtplib
from email.mime.text import MIMEText
def check_disk_usage(path='/', warning_threshold=80, critical_threshold=90):
"""ディスク使用率を確認してアラートを送信"""
total, used, free = shutil.disk_usage(path)
usage_percent = (used / total) * 100
free_gb = free / (1024 ** 3)
print(f"パス: {path}")
print(f"使用率: {usage_percent:.1f}%")
print(f"空き容量: {free_gb:.1f} GB")
if usage_percent >= critical_threshold:
send_alert(
level="CRITICAL",
message=f"{path} の使用率が {usage_percent:.1f}% です。"
f"空き容量: {free_gb:.1f} GB"
)
elif usage_percent >= warning_threshold:
send_alert(
level="WARNING",
message=f"{path} の使用率が {usage_percent:.1f}% です。"
f"空き容量: {free_gb:.1f} GB"
)
return usage_percent
def send_alert(level, message):
"""メールアラートを送信"""
msg = MIMEText(message)
msg['Subject'] = f"[{level}] ディスク容量アラート"
msg['From'] = "monitor@example.com"
msg['To'] = "admin@example.com"
with smtplib.SMTP('localhost') as server:
server.send_message(msg)
if __name__ == '__main__':
check_disk_usage('/')
check_disk_usage('/data')
紧急容量分配程序
如果发生 507 错误且服务停止,请按照以下步骤快速释放空间。
# 1. まず現状を把握
df -h
du -h --max-depth=1 / | sort -rh | head -10
# 2. 即座に削除できるファイル
# 古いログファイル(圧縮済み)
rm -f /var/log/nginx/*.gz
rm -f /var/log/syslog.*.gz
# パッケージマネージャーのキャッシュ
apt-get clean # Debian/Ubuntu
yum clean all # CentOS/RHEL
# 古いカーネル(Ubuntu)
apt-get autoremove --purge
# 3. 大きな不要ファイルを探して削除
find /var -type f -size +100M -mtime +30 -ls
find /tmp -type f -mtime +1 -delete
# 4. ログの即時ローテーション
logrotate -f /etc/logrotate.conf
# 5. journalctl のログを圧縮(systemd環境)
journalctl --vacuum-size=100M
journalctl --vacuum-time=7d
# 6. 削除後の確認
df -h
本文中可用的测试文件(免费)
- → <a href="/ja/files/threshold/png/50mb/" class="text-primary-600 dark:text-primary-400 hover:underline">50MB 边界值测试 PNG</a> — 用于大文件上传验证
- → <a href="/ja/files/threshold/png/10mb/" class="text-primary-600 dark:text-primary-400 hover:underline">10MB 边界值测试 PNG</a> — 用于存储写入基本测试
- → <a href="/ja/files/threshold/" class="text-primary-600 dark:text-primary-400 hover:underline">边界值测试文件列表</a> — 各种大小的测试文件
- → <a href="/ja/files/images/" class="text-primary-600 dark:text-primary-400 hover:underline">测试图像列表</a> — 用于验证上传功能
相关文章
- → <a href="/ja/blog/http-413-error/" class="text-primary-600 dark:text-primary-400 hover:underline">413 Request Entity Too Large 错误:原因和解决方案</a>
- → <a href="/ja/blog/http-422-error/" class="text-primary-600 dark:text-primary-400 hover:underline">422 Unprocessable Entity 错误:原因和解决方案</a>
- → <a href="/ja/blog/nginx-upload-config/" class="text-primary-600 dark:text-primary-400 hover:underline">Nginx 文件上传配置指南</a>
- → <a href="/ja/blog/s3-upload-limit/" class="text-primary-600 dark:text-primary-400 hover:underline">AWS S3・CloudFront 文件上传限制总结</a>