Astropy: ممكن يناسب خطأ memmap: memmap فقط لا يعمل.

تم إنشاؤها على ٢٦ أغسطس ٢٠١٣ · 12تعليقات · مصدر: astropy/astropy

أحاول تحميل بعض جداول تسجيل FITS العملاقة باستخدام memmap=True ، وأحصل على error: [Errno 12] Cannot allocate memory .

جلسة مثال:

filename = '/home/sdfits/AGBT12B_221_01/AGBT12B_221_01.raw.acs.fits'
import astropy.io.fits as fits
filefits = fits.open(filename,memmap=True)
data = filefits[2].data[:50]

الخطأ موجود في هذا السطر:

/users/aginsbur/anaconda/lib/python2.7/site-packages/numpy/core/memmap.py(253)__new__()
--> 253             mm = mmap.mmap(fid.fileno(), bytes, access=acc, offset=start)

ipdb> bytes
23718381056L
ipdb> bytes/1024**2
22619L
ipdb> start
413921280
ipdb> acc
3

لا أعرف حقًا ما الذي يحدث ، لكنني أظن أن memmap يقرر بشكل غير صحيح مقدار البيانات التي يجب قراءتها. أي نصائح حول كيفية إجراء مزيد من التصحيح؟ هل هذه في الواقع مشكلة FITS ، أو مشكلة معقدة؟

تفاصيل:

In [15]: numpy.__version__
Out[15]: '1.7.1'

In [16]: astropy.__version__
Out[16]: '0.2.4'

In [18]: sys.maxint
Out[18]: 9223372036854775807

Bug Effort-medium Package-intermediate io.fits

مصدر

keflavich

ال 12 كومينتر

ما نظام التشغيل؟

ماذا يعود ulimit -v ؟

embray في ٢٨ أغسطس ٢٠١٣

نظام التشغيل هو بعض نكهة لينكس. لا أعرف من أعلى رأسي أو
أسهل أمر لمعرفة ذلك.

أيضًا ، تم استخدام تثبيت anaconda من python / astropy / numpy ولكن تم ترقيته
نجمي عبر النقطة.

ulimit $ -v
غير محدود

في الثلاثاء ، 27 أغسطس 2013 ، الساعة 4:02 مساءً ، كتب إريك براي إخطارات github.com:

ما نظام التشغيل؟
ماذا يعود ulimit -v؟
-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/astropy/astropy/issues/1380#issuecomment -23374814
.

آدم

keflavich في ٢٨ أغسطس ٢٠١٣

ماذا يظهر cat /proc/meminfo ؟

embray في ٢٨ أغسطس ٢٠١٣

$ cat /proc/meminfo
MemTotal:        1903396 kB
MemFree:          203864 kB
Buffers:          215320 kB
Cached:           884708 kB
SwapCached:         2268 kB
Active:           492052 kB
Inactive:         954324 kB
Active(anon):     165684 kB
Inactive(anon):   181096 kB
Active(file):     326368 kB
Inactive(file):   773228 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1048568 kB
SwapFree:        1031460 kB
Dirty:                24 kB
Writeback:             0 kB
AnonPages:        344352 kB
Mapped:            65676 kB
Shmem:               432 kB
Slab:             191348 kB
SReclaimable:     151148 kB
SUnreclaim:        40200 kB
KernelStack:        2312 kB
PageTables:        22940 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2000264 kB
Committed_AS:     847268 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      286128 kB
VmallocChunk:   34359439336 kB
HardwareCorrupted:     0 kB
AnonHugePages:     12288 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8188 kB
DirectMap2M:     2070528 kB

keflavich في ٢٨ أغسطس ٢٠١٣

... هذا يبدو وكأنه قدر ضئيل من الذاكرة ؛ 2 جيجا بايت؟ هيرمف.

keflavich في ٢٨ أغسطس ٢٠١٣

@ keflavich - هل ما زلت ترى هذه المشكلة؟

astrofrog في ٣٠ نوفمبر ٢٠١٣

نسيت تماما عن هذا. MemTotal هو إجمالي الذاكرة الفعلية المتاحة فقط. 2 غيغابايت ليست كثيرة ، بالتأكيد ، لكن لا ينبغي أن تكون هذه هي المشكلة. لديك حوالي 32 تيرابايت مقابل VmallocTotal وهو ما يجب أن يكون مهمًا هنا - من حيث المبدأ يجب أن تكون mmap قادرة على استخدام معظم ذلك. لذلك هناك شيء مريب يحدث هنا.

embray في ٢ ديسمبر ٢٠١٣

آه! أعتقد أنني أرى المشكلة هنا. بشكل افتراضي ، يستخدم PyFITS MAP_PRIVATE عند فتح ملف في وضع القراءة فقط بحيث لا يزال بإمكان المستخدمين تعديل مجموعة البيانات في مكانها كما لو تم تعيين الملف بأكمله في الذاكرة الرئيسية.

تكمن المشكلة في أن هذا يعني من حيث المبدأ أنه يمكن الكتابة فوق الملف بأكمله ، لذلك يجب أن يكون mmap قادرًا على تخصيص ذاكرة كافية مسبقًا في حالة حدوث ذلك. لهذا السبب يحدث هذا هنا. يجب أن يلتقط PyFITS / Astropy هذا السيناريو بالتأكيد ويقدم خطأ أكثر فائدة.

يوجد حاليًا طريقتان للتغلب على هذا: يمكنك فتح الملف باستخدام mode='denywrite . لقد أضفت ذلك منذ فترة خصيصًا لهذه الحالة ، لكن نادرًا ما يتم استخدامه. هذا يفتح mmap بـ MAP_SHARED | PROT_READ هذا يعني أن الصفحات للقراءة فقط (أي محاولة لتعديل المصفوفة ستؤدي إلى استثناء). ولكن إذا كان كل ما تحتاجه هو قراءة البيانات ، فهذا يعمل بشكل جيد ، ولا يتطلب تخصيص أي مساحة تبادل لا أعتقدها.

الاحتمال الآخر هو الفتح بـ mode='update' . ثم يمكن مزامنة أي تغييرات على المصفوفة مباشرة مرة أخرى إلى الملف وهو أمر جيد إذا كنت تريد ذلك ، ولكن من الواضح أنه ليس كثيرًا إذا لم ترغب في ذلك.

بالنظر إلى صفحة الدليل ، يبدو أن هناك أيضًا علامة ، على الأقل في Linux ، تسمى MAP_NORESERVE والتي ستمنعها من تخصيص مساحة مسبقًا للنسخ عند الكتابة. لذلك إذا لم تكن بحاجة إلى كتابة أي تغييرات على المصفوفة بأكملها فقد تعمل أيضًا. لكن علينا أن نكون قادرين على التقاط SIGSEGV الذي ينتج إذا انتهى بك الأمر إلى نفاد مساحة التبادل.

embray في ٢ ديسمبر ٢٠١٣

تمكنت من إعادة إنتاج هذا بشكل مباشر - في الواقع ، كلا الحلين اللذين قدمتهما ( mode='denywrite' و mode='update' work. سأظل أحاول معرفة ما يمكنني فعله حول MAP_NORESERVE ، وغير ذلك التقاط هذا الخطأ وتقديم رسالة خطأ أفضل.

embray في ٤ ديسمبر ٢٠١٣

👍1

الإزعاج: numpy.memmap لا يسمح بتعديل الإشارات التي تم تمريرها إلى mmap call. على الرغم من النظر إليها ، فهي ليست أكثر من فئة فرعية خفيفة من ndarray تتعامل مع عمل إنشاء mmap مع الأعلام الصحيحة ثم استدعاء ndarray.__new__ باستخدام mmap كمخزن مؤقت لها. يضيف أيضًا طريقة flush .

يجب أن يكون من السهل تجنب استخدام numpy.memmap على الإطلاق والتعامل مع mmap بأنفسنا. لكن هذا لا يزال أكثر مما أريد القيام به في الوقت الحالي. لذا بدلاً من ذلك ، سأحل هذه المشكلة عن طريق اكتشاف الخطأ واقتراح أحد الحلول الحالية.

embray في ٤ ديسمبر ٢٠١٣

لاحظ أنه مع # 7597 لم نعد نستخدم np.memmap ، لذلك من الأسهل استخدام العلامات الأخرى إذا كان ذلك مفيدًا.

saimn في ٢٨ أغسطس ٢٠١٨

👍1

يمكن الآن إغلاق هذا ، حيث تم دمج حل بديل في https://github.com/astropy/astropy/pull/7926. MAP_NORESERVE غير متوفر من Python ، لذلك هذا ليس حلاً للأسف.

astrofrog في ٢٤ أكتوبر ٢٠١٨

👍1

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات