עבור לתוכן

מימוש זיכרון וירטואלי על הארד דיסק בc#

Featured Replies

פורסם

שלום,

אני עובד עכשיו על פרוייקט שמצריך עבודה על מספר רב של קבצים גדולים בו זמנית.

מה שקורה זה שאני כותב רכיבים שמקבל כל הזמן חתיכות קטנות של קבצים ומרכיב מהם קובץ גדול (לכל חתיכה יש מזהה לאיזה קובץ היא שייכת) עד שאני מקבל הודעה של סיום קובץ ואז אני שולח הלאה את הקובץ השלם.

החתיכות הן מאוד מאוד קטנות, באיזור ה500 בייט והקבצים הסופיים יכולים להיות די גדולים (בין כמה קילובייט לעשרות מגות).

מצד אחד אני לא רוצה להחזיק את כל הקבצים בזיכרון כי הוא ייגמר לי די מהר (אני עובד על Win2K Advanced Server עם 2 ג'יגה זיכרון לתהליך). אבל מצד שני אני לא רוצה לכתוב כל חתיכה לדיסק בגלל שאז אני אטחן IO בטירוף.

מה שעשיתי זה מימשתי באפר עבור כל קובץ שמחזיק byte[] של החתיכות הקטנות עד שהוא מגיע לגודל מסויים, ואז הוא מתרוקן לתוך הדיסק.

אבל חשבתי שאני לא ממציא פה את הגלגל, בטוח מישהו מימש כתיבה כזאת לדיסק בצורה חכמה וקיים DLL של כזה דבר באינטרנט. אני אשמח אם מישהו יפנה אותי למשהו כזה או יחשוב על רעיון יצירתי. שמעתי שאפשר להשתמש בקבצי SPARSE בNTFS, אבל לא הבנתי מה היתרונות ואם זה כזה חשוב.

תודה.

  • 4 שבועות מאוחר יותר...
פורסם

קצת קשה לי לענות לך - הבעיה לא ממש מוצגת טוב. כל שרת FTP מטפל בבעיות דומות לאלו שאתה מעלה פה ואף קשות יותר.

חסר מידע בנושאים הבאים:

1. כמה קבצים פתוחים יהיו בו זמנית? האם המספר חסום?

2. מה הפרוטוקול בין השולחים לשרת?

3. מי אמור לקבל את הקבצים אחרי שהעברתם הסתיימה?

4. האם יש הנחות מקדימות לפרוייקט? למשל שהשרת לא נכבה אף פעם בלי הכנה מוקדמת או בזמן שיש העברות פעילות

5. איך אתה מתכונן לדאוג שהזיכרון שאתה משתמש בו לא יעבור פייג'ינג ויוסיף בעצם קריאות וכתיבות מהדיסק?

אם תענה על השאלות האלו נוכל להתקדם בדיון.

דותן

פורסם
  • מחבר

דבר ראשון, תודה.

ניסיתי להיות בכוונה לא ממש ספציפי כדי לפשט את המצב.

1. לא חסום, בגדול, יכול להגיע לאיזור ה20 אלף (לאו דווקא אומר שכל ה20 אלף יהיו כתובים בדיסק)

2. IBMMQ, אבל איך זה רלוונטי?

3. גם כן IBMMQ

4. כן, השרת לא נכבה אף פעם. ובגדול, אני עכשיו רק עושה הוכחת ייתכנות לפני שאני כותב את זה בצורה יותר רצינית...

5. יש על השרת 4 ג'יגה זיכרון. תהליך לא יכול לתפוס יותר מ3, אז אני מניח שלא יכול להיות paging.

עוד משהו שגיליתי בשבוע האחרון הוא שכדאי לי להשתמש בGC בתצורת Server כדי להפוך אותו לmulti threaded (בשרת יש שני מעבדים עם HT)

פורסם

IBM MQ הוא כלי להעברת הודעות או message oriented middleware כמו שלפעמים קוראים לכלים כאלו.

ישנה אפשרות אני מניח להעביר אובייקט מסוג סטרים בינארי ולקבל אותו בשרת מבלי צורך לכתוב caching מעשה ידיך להתפאר. למרות שזו כביכול טענה טריויאלית אתה עלול לפגוע בביצועים של התוכנה עם תעבוד נגד הכלי שאתה משתמש בו במקום בהתאם למוד העבודה הטבעי שלו.

מה שנחוץ עכשיו לטעמי הוא הסבר יותר מפורט על אופי מעבר המידע במערכת. דהיינו דיון מושכל בנקודות הבאות:

1. מי יוזם מעבר של קבצים?

2. מה היא כמות הידע של השרת לגבי גודל הקבצים שעוברים דרכו ומתי הסתיימה העברת קובץ?

3. מי מקבל את הקובץ אחרי שהעברתו הסתיימה ואיך זה נקבע?

נראה לי שאתה מנסה להשליך על MQ מיני דברים שהוא לא אמור לעשות ולוקח ממנו תחומי אחריות שהוא כן אמור לנהל. בסופו של דבר תמצא את עצמך עם ים של לוגיקה שנמצאת בכל מיני הנדלרים של השרת ולא תוכל לעשות בה כלום אם תרצה בעתיד לעבור למימוש אחר של JMS (אני מניח שזה בעצם מה שאתה חושב שאתה זקוק לו).

ל-MQ יש גם כלי נוסף בסדרה שנקרא workflow manager שבא לעזור בדיוק במצבים שבהם רוצים לקבוע תהליך עסקי שיש בו מספר משתתפים שמדברים ביניהם באמצעות הודעות. אני מניח שזה הרבה יותר מורכב ממה שאתה זקוק לו אבל מצד שני MQ הוא בעצמו חתיכת מפלצת שאני לא ממש מבין למה אתה רוצה להשתמש דווקא בה.

דותן

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

דיונים חדשים