VPS का सही benchmark कैसे लें: yabs.sh और fio

VPS का बेंचमार्क लेने का अर्थ

VPS का बेंचमार्क लेने के लिए आप 4 चीज़ें मापते हैं: एक CPU core कितनी तेज़ी से चलता है, मशीन की memory bandwidth कितनी है, storage हर सेकंड कितने छोटे random disk operations पूरा करता है, और network link कितना throughput देता है। yabs.sh का एक run लगभग 10 मिनट में ये चारों माप देता है। परिणाम को समझना कठिन भाग है, क्योंकि VPS (virtual private server) भौतिक hardware को अन्य tenants के साथ साझा करता है। इसलिए वही मशीन 03:00 बजे एक संख्या और 20:00 बजे उससे बहुत अलग संख्या दिखा सकती है।

यहाँ योजना पहले त्वरित जानकारी के लिए yabs.sh चलाने की है। इसके बाद इसके अंदर उपयोग होने वाले tools को manually चलाएँ। इन्हें स्वयं चलाने पर आप एक flag बदल सकते हैं, संख्या में आया बदलाव देख सकते हैं और समझ सकते हैं कि वह संख्या वास्तव में क्या माप रही थी। यह काम मशीन के setup होने के बाद करें, पहले नहीं। नए VPS पर पहले 10 मिनट में दिए गए steps पहले पूरे करें। इसका कारण यह है कि जो box अभी updates का पहला batch लागू कर रहा हो, उसका benchmark खराब परिणाम देता है और इसका hardware से कोई संबंध नहीं होता।

मापने से पहले मशीन की जाँच करें

हर खराब बेंचमार्क का आधा कारण ऐसी मशीन होती है जिसे लेखक ने समझा नहीं था।

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM का अर्थ पूर्ण वर्चुअलाइज़ेशन है, इसलिए आप अपना kernel चलाते हैं। systemd-detect-virt में lxc या openvz का प्रिंट होना container वर्चुअलाइज़ेशन का संकेत है। इसमें आप host kernel साझा करते हैं, और आपकी CPU तथा memory सीमाएँ वर्चुअल hardware के बजाय cgroup (control group) सेटिंग होती हैं। cgroup v2 सिस्टम पर आप CPU सीमा सीधे पढ़ सकते हैं।

cat /sys/fs/cgroup/cpu.max

max 100000 का अर्थ है कि कोई quota नहीं है। 200000 100000 का अर्थ है कि प्रत्येक df -hT / अवधि में आप CPU के 200000 microseconds उपयोग कर सकते हैं, जो दो cores के quota के बराबर है। दो cores के quota वाला 4 vCPU के रूप में विज्ञापित plan कभी भी चार cores जैसा score नहीं देगा, और कोई benchmark tool आपको यह बताने वाली पंक्ति प्रिंट नहीं करता कि ऐसा क्यों है।

df -hT / एक अलग कारण से महत्वपूर्ण है: Type column। यदि इसमें overlay पढ़ा जाए, तो आप container के अंदर हैं और नीचे दिया गया disk test बदलना होगा। अभी इसे नोट कर लें।

पूरे समय steal time पर नज़र रखें

Steal time उस समय का हिस्सा है जब आपका virtual CPU चलने के लिए तैयार था, लेकिन hypervisor ने physical core किसी दूसरे को दे दिया। यह बताने वाला सबसे उपयोगी एकल संकेत है कि परिणाम आपके पड़ोसी tenants के कारण है, hardware के कारण नहीं।

vmstat 1 10

दाईं ओर st column पढ़ें। लगातार 0 या 1 सामान्य है। 5 से अधिक के लगातार मानों का अर्थ है कि उस समय host पर जरूरत से अधिक workload है। इसलिए उस अवधि में दर्ज की गई हर CPU संख्या आपकी machine की गलती के बिना कम होगी। top CPU line पर %st के समान आंकड़ा दिखाता है। Benchmark चलाते समय vmstat 1 को दूसरे SSH session में चलाते रहें और हर परिणाम के साथ steal figure लिखें।

yabs.sh से शुरुआत करें

yabs.sh (Yet Another Bench Script) एक shell script है। यह static fio, iperf3 और Geekbench binaries डाउनलोड करती है, उन्हें चलाती है और एक सारांश दिखाती है। VPS benchmark चर्चाओं में इसका उपयोग सामान्य है। इसलिए किसी अन्य व्यक्ति के परिणामों से तुलना करने का सबसे तेज़ तरीका yabs output है।

इस project का अपना one-line रूप यह है।

curl -sL yabs.sh | bash

यह URL से मिलने वाली सामग्री को सीधे shell में भेजता है। पहले इसे download करें, पढ़ें और फिर चलाएँ।

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

जब आप pipe का उपयोग करते हैं, तो flags -s -- के बाद लगाएँ। Local copy चलाते समय flags को filename के तुरंत बाद रखें। उपयोगी विकल्प ये हैं: -f disk test को छोड़ता है, -i network test को छोड़ता है, -g Geekbench को छोड़ता है, -r iperf3 locations की संख्या घटाकर दो करता है, -j परिणामों को JSON के रूप में दिखाता है और -w results.json उस JSON को file में लिखता है।

bash yabs.sh -r -w yabs-run1.json

पहली बार चलाने से पहले दो बातें जान लें। Geekbench आपके परिणाम upload करता है और public browser.geekbench.com URL दिखाता है। इसलिए जिस किसी के पास वह link है, वह आपके CPU model और scores पढ़ सकता है। -g इस test को पूरी तरह छोड़ता है। दूसरी बात, iperf3 stage कई regions में स्थित servers को वास्तविक network traffic भेजता है। यह आपके monthly bandwidth allowance में गिना जाता है। 1 Gbit/s link पर पूरा network stage tens of gigabytes traffic भेज सकता है। इसलिए कम allowance पर -r और metered link पर -i उपयोग करें।

yabs आउटपुट के प्रत्येक भाग का अर्थ

डिस्क अनुभाग 4k, 64k, 512k और 1m के चार block sizes पर 50/50 read और write मिश्रण के साथ fio चलाता है। यह प्रत्येक block size के लिए IOPS (input/output operations per second) और bandwidth रिपोर्ट करता है। Database, mail server या बहुत-सी छोटी writes करने वाले किसी भी workload के लिए 4k वाली row महत्वपूर्ण है, क्योंकि अधिकांश server IO छोटा और बिखरा हुआ होता है। 1m वाली row backups और video के लिए महत्वपूर्ण है, जहाँ bytes की लंबी श्रृंखलाएँ स्थानांतरित की जाती हैं।

Network अनुभाग कई regions में public servers के विरुद्ध, दोनों दिशाओं में, parallel streams का उपयोग करके iperf3 चलाता है। यहाँ कम संख्या को अंतिम निष्कर्ष के बजाय जाँच का संकेत मानें, क्योंकि public iperf3 servers साझा होते हैं और अक्सर saturated रहते हैं। इसलिए खराब परिणाम दूर वाले endpoint के कारण भी हो सकता है।

Geekbench अनुभाग single core score और multi core score देता है। Single core score बताता है कि एक request, एक compile या एक query कितनी जल्दी पूरी होती है। Multi core score मुख्यतः यह बताता है कि आपको वास्तव में कितने cores मिले हैं।

Disk: स्वयं fio चलाएँ

fio (flexible IO tester), yabs के disk section के पीछे उपयोग होने वाला tool है। इसे सीधे चलाने पर इसके flags का अर्थ स्पष्ट होता है।

sudo apt update && sudo apt install -y fio sysbench iperf3

जिस filesystem की आपको वास्तव में परवाह है, उस पर queue depth 32 के साथ 4k random read test:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

Output में पढ़ी जाने वाली summary line इस तरह दिखती है।

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

इसके नीचे fio एक clat percentiles block print करता है। 99.00th percentile वह आंकड़ा है जिसे उद्धृत करना उचित है, क्योंकि यह बताता है कि 100 में से सबसे धीमे 1 request को कितनी देर प्रतीक्षा करनी पड़ी। औसत latency उन stalls को छिपा देती है जिन्हें user महसूस करता है।

• --direct=1 file को O_DIRECT के साथ खोलता है, इसलिए reads kernel page cache को bypass करते हैं। इसके बिना, 8G RAM वाली machine पर 2G file का दूसरा pass memory से serve होता है और fio लाखों में IOPS report करता है। यह संख्या वास्तविक है, लेकिन यह memory की संख्या है।
• --ioengine=libaio asynchronous requests submit करता है। इससे --iodepth=32 32 requests को in flight रख सकता है। psync जैसे synchronous engine के साथ 1 से अधिक iodepth का कोई प्रभाव नहीं होता। इसलिए आप एक समय में केवल 1 request measure करते हैं।
• --time_based --runtime=60 fixed amount of work के बजाय fixed 60 seconds तक चलता है। इससे fast disk और slow disk को समान wall clock मिलता है और comparison निष्पक्ष रहता है।
• --size=2G test file का size set करता है। इसे path में मौजूद किसी भी cache से बड़ा रखें और पहले जाँच लें कि पर्याप्त free space है।

Random write के लिए यही command --rw=randwrite के साथ चलाएँ। इसे अलग से चलाएँ और फिर file delete करें।

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

वास्तविक traffic के अधिक निकट mix के लिए --rw=randrw --rwmixread=70 का उपयोग करें। आप किस class के storage पर हैं, इससे इन results में किसी भी flag की तुलना में अधिक बदलाव आता है। इस अंतर को VPS पर NVMe और SATA SSD storage के बीच का अंतर में समझाया गया है।

जब fio Unknown error -1 के साथ रुकता है

हर filesystem पर Direct IO उपलब्ध नहीं होता। overlay, वह filesystem जिसे Docker डिफ़ॉल्ट रूप से किसी container को देता है, और कई network filesystems O_DIRECT का समर्थन नहीं करते। इसलिए libaio ऐसा अनुरोध kernel को भेजता है जिसे kernel पूरा नहीं कर सकता, और fio रुक जाता है:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

पहले df -hT . चलाएँ। यदि Type column में overlay लिखा है, तो --filename को real storage के किसी path पर निर्देशित करें, जैसे bind mounted volume, या container के बजाय host पर fio चलाएँ। यदि real storage उपलब्ध नहीं है, तो buffered synchronous run कम-से-कम यह साबित करता है कि command स्वयं सही है।

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

इस run के बारे में सही जानकारी दें। पहले pass के बाद 256M file page cache में रहती है, इसलिए IOPS का आंकड़ा आपकी RAM को दर्शाता है। इसका उपयोग यह पुष्टि करने के लिए करें कि fio installed है और flags सही तरह parse होते हैं। इसे disk result के रूप में कभी उद्धृत न करें।

dd डिस्क बेंचमार्क क्यों नहीं है

dd कई VPS चर्चाओं में दिखाई देता है, और यह केवल एक सीमित प्रश्न का उत्तर देता है।

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

यह एक thread और एक समय में एक request के साथ sequential write throughput मापता है। यह एक उचित sanity check है। यह random IO के बारे में कुछ नहीं बताता। यह भी नहीं बताता कि एक साथ 32 requests आने पर क्या होता है। oflag=direct हटाने पर यह मुख्यतः यह मापता है कि आपका kernel memory में writes कितनी तेजी से स्वीकार करता है। इसी कारण forum posts में उद्धृत dd के आंकड़े अक्सर अवास्तविक होते हैं।

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

ध्यान रखने योग्य आंकड़ा events per second है। पहले single threaded परीक्षण चलाएँ। यह बताता है कि एक PHP request कितनी जल्दी पूरी होती है या एक compile job कितनी जल्दी पूरी होती है। समान कीमत वाले hosts के बीच इसमें सबसे अधिक अंतर होता है। इसके बाद हर thread के साथ परीक्षण चलाएँ। इससे पता चलता है कि आपके vCPUs अलग-अलग cores हैं या एक ही core के हिस्से हैं।

यह स्पष्ट रखें कि यह परीक्षण क्या मापता है: sysbench cpu, 64 bit integer arithmetic का उपयोग करके बार-बार prime numbers खोजता है। यह memory bandwidth, vector units या cache को वास्तविक workload जैसी किसी स्थिति में stress नहीं करता। इसलिए यह दो hosts की ranking के लिए उपयोगी है, लेकिन यह अनुमान लगाने के लिए उपयुक्त नहीं है कि आपका application कैसे चलेगा।

Ubuntu 24.04 में sysbench 1.0.20 आता है। इसमें test name पहले लिखा जाता है। पुराने post से --test=cpu वाला command copy करने पर आपको WARNING: the --test option is deprecated मिलता है। sysbench 0.4 और sysbench 1.0 के scores की आपस में बिल्कुल तुलना नहीं की जा सकती। इसलिए कभी भी ऐसे published number से अपनी तुलना न करें जिसमें उसका version न दिया गया हो।

मेमोरी: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

परिणाम MiB/sec में होता है, और हर मशीन पर read की गति write से अधिक होती है। --memory-block-size को 1M पर रखें और जिन सभी host की तुलना करें, उनमें इसका मान समान रखें। 1K पर संख्या बहुत कम हो जाती है, क्योंकि प्रत्येक operation का overhead आपको 1000 गुना अधिक बार चुकाना पड़ता है। इसलिए आप memory bandwidth के बजाय loop cost मापने लगते हैं। प्रकाशित memory scores में यही flag सबसे अधिक बार असंगत होता है।

Network: iperf3

थ्रूपुट का परीक्षण करने का सही तरीका यह है कि इसे आपके नियंत्रण वाली दूसरी मशीन के विरुद्ध किया जाए। इससे आपको पता रहता है कि दोनों सिरों पर क्या हो रहा है।

दूर वाली मशीन पर:

iperf3 -s

यह TCP 5201 पर सुनता है। पोर्ट को केवल उस address के लिए खोलें जिससे आप परीक्षण कर रहे हैं। परीक्षण पूरा होने पर इसे बंद कर दें। VPS पर Basic ufw firewall rules में syntax दिया गया है।

परीक्षण किए जा रहे VPS से:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

पहला command परीक्षण की जा रही मशीन से upload मापता है। -R दिशा को उलट देता है और download मापता है। -P 8 आठ parallel streams खोलता है।

Single stream और parallel version, दोनों चलाएँ। वे अलग-अलग प्रश्नों के उत्तर देते हैं। एक TCP connection उतना ही unacknowledged data रख सकता है जितना उसका window अनुमति देता है। इसलिए इसकी अधिकतम दर लगभग window size को round trip time से विभाजित करने के बराबर होती है। 80 ms latency और 4 MB window पर यह सीमा लगभग 400 Mbit/s होती है, चाहे underlying link कितनी भी तेज हो। Single stream का आंकड़ा बताता है कि एक download को कितनी गति मिलेगी। Parallel आंकड़ा link की capacity बताता है।

यह परीक्षण करते समय अपने bandwidth allowance पर नज़र रखें। 1 Gbit/s पर 30 seconds में लगभग 3.75 GB data transfer होता है। आप इसे प्रत्येक दिशा में कई बार चलाएँगे।

संदर्भ आंकड़े और अपने परिणाम को समझने का तरीका

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

प्रकाशित परिणामों में स्थानीय NVMe वॉल्यूम आमतौर पर 180,000 4k रैंडम रीड IOPS के आसपास रहता है। स्थानीय SATA SSD का परिणाम लगभग 90,000 होता है। नेटवर्क-अटैच्ड ब्लॉक स्टोरेज में हर अनुरोध डिस्क तक पहुंचने से पहले नेटवर्क से होकर गुजरता है, इसलिए इसका परिणाम 12,000 के अधिक निकट रहता है। स्पिनिंग डिस्क लगभग 180 प्राप्त करती है, क्योंकि हर रैंडम अनुरोध के लिए उसे भौतिक हेड को स्थानांतरित करना पड़ता है।

ये प्रत्येक स्टोरेज श्रेणी के सामान्य प्रकाशित आंकड़े हैं। ये किसी एक host से लिए गए माप नहीं हैं। इनका उपयोग केवल यह जांचने के लिए करें कि आपका अपना परिणाम सही परिमाण के आसपास है। यदि NVMe के रूप में बेची गई कोई योजना 4k IOPS के कम हजारों में benchmark परिणाम देती है, तो पहले पुष्टि करें कि --direct=1 चालू था। यदि वह चालू था, तो या तो स्टोरेज product page में बताए गए प्रकार का नहीं है, या आप इसे बहुत व्यस्त पड़ोसी के साथ साझा कर रहे हैं।

एक रन बेंचमार्क क्यों नहीं है

एक परिणाम साझा मशीन पर एक मिनट का स्नैपशॉट होता है। इसे एक नमूने के रूप में लें।

• हर परीक्षण कम से कम पांच बार चलाएँ। इन्हें अलग-अलग घंटों और कम से कम दो अलग दिनों में फैलाएँ। माध्यिका और फैलाव दर्ज करें। फैलाव के बिना प्रकाशित परिणाम मार्केटिंग आँकड़ा होता है।
• हर रन के साथ steal time दर्ज करें। जिन रन में st अधिक था, उन्हें हटा दें। कम से कम यह नोट करें कि वह अधिक था।
• डिस्क परीक्षण को दो अवधियों पर चलाएँ। कई प्लान burst IOPS allowance देते हैं, जो समय के साथ फिर भरता है। इसलिए 60 सेकंड का fio रन burst को मापता है, जबकि --runtime=600 न्यूनतम स्तर को मापता है। खराब दिन में आपको यही न्यूनतम स्तर मिलता है।
• जाँचें कि कोई अन्य कार्य नहीं चल रहा है। CPU परीक्षण के बीच unattended-upgrades का apt transaction शुरू करना आपके वास्तविक स्कोर को घटाता है। हर रन से पहले ps -e -o comm= | grep -E 'apt|dpkg' चलाने में एक सेकंड लगता है।
• एक समय में केवल एक variable बदलें। अलग-अलग tool versions, block sizes या thread counts ऐसे आँकड़े देते हैं जिनकी तुलना नहीं की जा सकती, भले ही वे देखने में समान लगें।

जब आप दो providers की तुलना करें, तो उन्हें उसी दिन उसी घंटे चलाएँ। अन्यथा आपने दिन के समय को मापा है।

अपने कार्यभार का बेंचमार्क सबसे अंत में करें

सिंथेटिक टूल मशीनों की रैंकिंग करते हैं। केवल आपका अपना कार्यभार बताता है कि मशीन पर्याप्त है या नहीं। उसी कार्य को समयबद्ध करें जिसे आप वास्तव में करते हैं।

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

यह कुछ सौ मेगाबाइट को संपीड़ित करता है। इसलिए इसमें CPU और डिस्क दोनों का उपयोग होता है, और इनमें से किसी में भी बदलाव होने पर परिणाम बदलता है। Removing leading / from member names चेतावनी सामान्य है। इससे भी बेहतर है कि अपने build, अपनी सबसे धीमी query या अपने page render का समय मापें। किसी host पर build में 4 मिनट और दूसरे पर 7 मिनट लगना प्रश्न का उत्तर दे देता है, चाहे Geekbench का परिणाम कुछ भी हो। यही माप आपको यह भी बताता है कि अधिक मशीन के लिए भुगतान करना कब लाभकारी नहीं रहता। यह जानना उपयोगी है, इससे पहले कि आप VPS की मासिक वास्तविक लागत पढ़ें या कार्यभार को dedicated server पर ले जाएँ।

FAQ

हर बार चलाने पर मुझे अलग बेंचमार्क परिणाम क्यों मिलता है?

एक VPS भौतिक CPU, storage और network को अन्य tenants के साथ साझा करता है। इसलिए आपका परिणाम उस समय उनके किए जा रहे कार्यों पर निर्भर करता है। परीक्षण के दौरान vmstat 1 चलाएँ और st column पढ़ें: 5 से अधिक का लगातार steal time बताता है कि host व्यस्त था, इसलिए आपके CPU score का कम होना आपकी machine के बाहर के कारणों से है। इसका समाधान tuning नहीं, बल्कि सही method है। प्रत्येक परीक्षण को अलग-अलग hours में पांच या अधिक बार चलाएँ। इसके बाद spread के साथ median रिपोर्ट करें।

fio लाखों IOPS क्यों दिखाता है?

लगभग हमेशा इसका कारण --direct=1 का न होना है। इसके बिना fio kernel page cache के माध्यम से पढ़ता है। इसलिए पहले pass के बाद 2G test file RAM से उपलब्ध होती है और आपने memory bandwidth मापी होती है। --direct=1 जोड़ें और test file को path में मौजूद किसी भी cache से बड़ा रखें। यदि --direct=1 इसके बाद err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 के साथ fail हो, तो df -hT . चलाएँ। overlay का Type O_DIRECT support नहीं करता। इसलिए परीक्षण को वास्तविक storage पर चलाएँ।

क्या yabs.sh अपने आप पर्याप्त है?

पहले अवलोकन के लिए, हाँ। यह चार block sizes पर fio, दोनों दिशाओं में iperf3 और Geekbench चलाता है। यह एक ऐसी summary भी दिखाता है जिसे दूसरे लोग पढ़ सकते हैं। जब आप यह जानना चाहते हैं कि कोई number ऐसा क्यों है, तब यह पर्याप्त नहीं रहता, क्योंकि आप प्रत्येक test के लिए इसके flags बदल नहीं सकते। जब yabs का परिणाम गलत लगे, तो उसे सीधे fio या sysbench से दोबारा चलाएँ और एक बार में एक flag बदलें।

कौन-सा एक number यह बताता है कि मेरा application कैसा महसूस होगा?

अधिकांश web और database workloads के लिए, पहले single core CPU speed और उसके बाद 4k random read latency सबसे महत्वपूर्ण हैं। Throughput figures प्रभावशाली दिखते हैं, लेकिन आम तौर पर कोई निर्णय नहीं लेते, क्योंकि सामान्य request छोटी होती है। औसत के बजाय fio clat percentiles block से 99th percentile लिखें। प्रत्येक 100 requests में से धीमी request ही वह होती है जिसे user महसूस करता है।

क्या benchmarking से पहले मुझे कुछ install करना आवश्यक है?

fio, sysbench और iperf3 सभी Ubuntu और Debian archives में उपलब्ध हैं: sudo apt install -y fio sysbench iperf3। yabs.sh को केवल curl की आवश्यकता होती है, क्योंकि जो कुछ missing हो उसके लिए यह static binaries download करता है। काम पूरा होने पर प्रत्येक test file delete करें। 20G disk पर छोड़ी गई 2G fio file कई सप्ताह बाद किसी के disk full alert का कारण बन सकती है।