ചിത്രങ്ങൾ നിറഞ്ഞ ഏജന്റ് ടേണുകൾ മെമ്മറിക്കുള്ളിൽ നിർത്തുന്നു

ഒരു പ്രൊഡക്ഷൻ ഏജന്റ് ടേൺ ആറ് കാറ്റലോഗ് സ്കാനുകളിൽ നിന്ന് ഉൽപ്പന്നങ്ങൾ crop ചെയ്ത് അവയുടെ crop-കൾ നോക്കിക്കൊണ്ടിരുന്നപ്പോൾ 952 MB-യിൽ മെമ്മറി തീർന്നു. ഒരു ലീക്കല്ല ഉണ്ടായിരുന്നത്, മൂന്നെണ്ണം ആയിരുന്നു. മോഡലിലേക്ക് ഓരോ കോളിലും ടേണിലെ ചിത്രങ്ങൾ മുഴുവൻ വലുപ്പത്തിൽ വീണ്ടും അയച്ചു; മോഡൽ കോളിംഗ് ലൈബ്രറി ഓരോ അഭ്യർത്ഥനയും ടേൺ അവസാനിക്കുന്നതുവരെ ജീവനോടെ നിലനിർത്തി; ഏജന്റ് ഫ്രെയിംവർക്കിന്റെ ട്രേസിംഗ് ഓരോ കോളിന്റെയും ഇൻപുട്ടുകൾ, ചിത്രങ്ങളും ഉൾപ്പെടെ, ടേൺ മുഴുവൻ സൂക്ഷിച്ചു. മൂന്നും ഞങ്ങൾ പരിഹരിച്ചു: അയക്കുന്നതിന് മുമ്പ് ചിത്രങ്ങൾ ചെറുതാക്കുന്നു, ഓരോ കോളിന്റെയും ചിത്രങ്ങൾ കോൾ കഴിഞ്ഞാലുടൻ വിട്ടയക്കുന്നു.

ഏജന്റ് ചിത്രങ്ങൾ എങ്ങനെ കാണുന്നു

Mythex-ൽ നിർമ്മിക്കുമ്പോൾ ഏജന്റ് നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ ക്ലൗഡ് സാൻഡ്‌ബോക്സിനുള്ളിലാണ് പ്രവർത്തിക്കുന്നത്. നിങ്ങൾ അറ്റാച്ച് ചെയ്യുന്ന സ്ക്രീൻഷോട്ട്, മോക്കപ്പ്, പ്രോജക്റ്റിലെ ഒരു ഫയൽ, അല്ലെങ്കിൽ അത് സ്വയം ഉണ്ടാക്കിയ ഒരു ചിത്രം എന്നിവ അതിന് നോക്കാം. സംഭാഷണത്തോടൊപ്പം ചിത്രം മോഡലിലേക്ക് അയച്ചാണ് ഇത് ചെയ്യുന്നത്.

ടേൺ എന്നാൽ ഒരു സന്ദേശത്തിന് മറുപടിയായി ഏജന്റ് ചെയ്യുന്നതെല്ലാമാണ്. ഒരു ടേണിനുള്ളിൽ ഏജന്റ് മോഡലിനെ പലതവണ വിളിക്കുന്നു: ചിന്തിക്കുന്നു, ഒരു ടൂൾ പ്രവർത്തിപ്പിക്കുന്നു, ഫലം നോക്കുന്നു, വീണ്ടും ചിന്തിക്കുന്നു. ഓരോ കോളും ഇതുവരെയുള്ള സംഭാഷണം അയക്കുന്നു; അതിൽ ടേണിലെ ചിത്രങ്ങളും base64 ആയി ടെക്സ്റ്റായി ഉൾപ്പെടുന്നു (ഇത് ഏകദേശം മൂന്നിലൊന്ന് വലുതാക്കുന്നു).

മെമ്മറി തീർന്ന ടേൺ ഒരു ന്യായമായ കാര്യമാണ് ചെയ്തുകൊണ്ടിരുന്നത്. ആറ് കാറ്റലോഗ് സ്കാനുകൾ, ഓരോന്നും ഏകദേശം 2.4 MB, എടുത്ത് അവയിൽ നിന്ന് വ്യക്തിഗത ഉൽപ്പന്നങ്ങൾ crop ചെയ്തു, crop-കൾ വീണ്ടും വായിച്ച് പരിശോധിച്ചു. അതിന് ഒരുപാട് മോഡൽ കോളുകൾ വേണ്ടിവന്നു, ഓരോന്നിലും പല വലിയ ചിത്രങ്ങൾ ഉണ്ടായിരുന്നു.

കാരണം 1: ഓരോ കോളും മുഴുവൻ വലുപ്പത്തിലുള്ള ചിത്രങ്ങൾ വീണ്ടും അയച്ചു

ഓരോ മോഡൽ കോളും അതിന്റെ അഭ്യർത്ഥനാ ബോഡി വീണ്ടും നിർമ്മിച്ചു, ടേണിലെ ചിത്രങ്ങൾ മുഴുവൻ വലുപ്പത്തിൽ, ഓരോ കോളിലും ഏകദേശം 20 MB base64. ബോഡി ഏജന്റിന്റെ മെമ്മറിയിൽ ഒരൊറ്റ സ്ട്രിംഗായാണ് നിർമ്മിക്കുന്നത്, അതിനാൽ ഓരോ കോളും മറ്റൊരു ~20 MB അനുവദിച്ചു.

മുഴുവൻ വലുപ്പത്തിൽ അയക്കുന്നത് ഒന്നും നേടിയിരുന്നില്ല. വലിയ വശം ഏകദേശം 1,300 പിക്സലിലേക്ക് മോഡൽ തന്നെ ചിത്രം ചെറുതാക്കുന്നു; അധിക പിക്സലുകൾ മെമ്മറിയും അപ്‌ലോഡ് സമയവും മാത്രം ചെലവാക്കി.

പരിഹാരം: ഒരിക്കൽ ചെറുതാക്കുക, ചെറുതായി അയക്കുക

• 400 KB-യിൽ കൂടുതലുള്ള ചിത്രങ്ങൾ അയക്കുന്നതിന് മുമ്പ് വലിയ വശത്ത് പരമാവധി 1,568 പിക്സലുള്ള JPEG ആയി മാറ്റുന്നു. ചെറിയ ചിത്രങ്ങൾ ഉള്ളതുപോലെ പോകുന്നു.
• പരിവർത്തനം ഓരോ ഫയലിനും ഒരിക്കൽ മാത്രം ImageMagick ഉപയോഗിച്ച് നടക്കുന്നു; ImageMagick ഓരോ Mythex സാൻഡ്‌ബോക്സിലും ഉണ്ട്. ഓരോ കോളിലും ഒരേ സ്കാനുകൾ കാണിക്കുന്ന ഒരു ടേൺ ചെറുതാക്കിയ പകർപ്പ് വീണ്ടും ഉപയോഗിക്കുന്നു. ആ കാഷെ ഫയലിന്റെ പാത്ത്, വലുപ്പം, മോഡിഫിക്കേഷൻ സമയം എന്നിവ കീയാക്കി വെച്ചിരിക്കുന്നു, അതിനാൽ എഡിറ്റ് ചെയ്ത ഫയൽ വീണ്ടും മാറ്റുന്നു; അതിന് സ്വന്തം വലുപ്പ പരിധിയുമുണ്ട്, അതിനാൽ അത് തന്നെ മെമ്മറി നിറയ്ക്കുന്ന കാരണമാകില്ല.
• ഒരു മോഡൽ കോളിലെ ചിത്രങ്ങൾക്കുള്ള ബജറ്റ് 16 MB-യിൽ നിന്ന് 6 MB-ആയി കുറയുന്നു.

അതേ ആറ് സ്കാനുകൾ ഇപ്പോൾ ഓരോ കോളിനും 19.7 MB-ക്ക് പകരം 4.4 MB ചെലവാക്കുന്നു.

കാരണം 2: മോഡൽ ക്ലയന്റ് ഒരു അഭ്യർത്ഥനയും വിട്ടയച്ചില്ല

ഓരോ അഭ്യർത്ഥനയുടെയും വലുപ്പം മാത്രമല്ല പ്രശ്നം. മെമ്മറി ഓരോ കോളിലും വളരുകയും ചെയ്തു. ഞങ്ങളുടെ സ്റ്റേജിംഗ് പരിസ്ഥിതിയിൽ അതേതരം ടേൺ, ഒരു പൂർണ്ണ garbage collection കഴിഞ്ഞും 369 MB ലൈവ് മെമ്മറി പിടിച്ചുവെച്ചു. അതായത്, ഒന്നും എത്തിച്ചേരാനാകാത്തതായി മാറുമ്പോൾ മെമ്മറി സ്വതന്ത്രമാക്കുന്ന ഘട്ടം കഴിഞ്ഞും. ഹീപ്പ് സാമ്പിളിംഗ് വളർച്ച മുഴുവൻ മോഡൽ ക്ലയന്റ് ലൈബ്രറിയിലെ അഭ്യർത്ഥനാ ബോഡികൾ എൻകോഡ് ചെയ്യുന്ന ഭാഗത്താണെന്ന് കാണിച്ചു.

കാരണം ഒരു abort listener ആയിരുന്നു. നിങ്ങൾ Stop അമർത്തുമ്പോൾ ടേണിന്റെ abort signal പുറപ്പെടുന്നു, അതിനെ കേൾക്കുന്ന ഓരോ അഭ്യർത്ഥനയും റദ്ദാകുന്നു. ഞങ്ങൾ ആ ഒരൊറ്റ ടേൺ-വ്യാപകമായ signal ഓരോ അഭ്യർത്ഥനയ്ക്കും കൈമാറി. ക്ലയന്റ് ലൈബ്രറി നൽകിയ signal-ൽ ഒരു "abort" listener ചേർക്കുന്നു, പക്ഷേ അത് ഒരിക്കലും നീക്കം ചെയ്യുന്നില്ല.

അങ്ങനെ ഒരു ടേണിലെ ഓരോ അഭ്യർത്ഥനയും ടേൺ നീളുന്നിടത്തോളം ടേണിന്റെ signal-ൽ നിന്ന് എത്തിച്ചേരാവുന്നതായി നിന്നു: listener, അത് പിടിച്ച controller, അത് പിടിച്ച അഭ്യർത്ഥന, അതിൽ ചിത്രങ്ങളോടൊപ്പമുള്ള മുഴുവൻ ബോഡിയും.

പരിഹാരം: ഒരു അഭ്യർത്ഥനയ്ക്ക് ഒരു signal

ഓരോ അഭ്യർത്ഥനയ്ക്കും ഇപ്പോൾ സ്വന്തം signal ലഭിക്കുന്നു. അത് അഭ്യർത്ഥന നടക്കുന്ന സമയത്ത് മാത്രം ടേണിന്റെ signal-മായി ബന്ധിപ്പിക്കുന്നു, സ്ട്രീം ചെയ്ത പ്രതികരണത്തിന് അവസാന chunk വായിക്കുന്നതുവരെ, പിന്നെ ഉടൻ വിച്ഛേദിക്കുന്നു. Stop ഇപ്പോഴും പറക്കുന്ന ഏത് അഭ്യർത്ഥനയിലും എത്തുന്നു, പക്ഷേ ടേണിന്റെ signal ഒരു സമയം ഒരു listener മാത്രമേ പിടിക്കൂ.

ടെസ്റ്റുകൾ ഈ മൂന്ന് ഭാഗങ്ങളും കവർ ചെയ്യുന്നു:

• 12 കോളുകൾക്ക് ശേഷം, ടേണിന്റെ signal-ൽ ഒരു listener പോലും ശേഷിക്കുന്നില്ല. പരിഹാരത്തിന് മുമ്പ് 12 ഉണ്ടായിരുന്നു.
• 8 MB വീതമുള്ള 15 അഭ്യർത്ഥനകൾക്ക് മുകളിൽ മെമ്മറി സ്ഥിരമായി തുടരുന്നു. മുമ്പ് അത് 128 MB വളർന്നിരുന്നു.
• ഒരു അഭ്യർത്ഥന സ്ട്രീമിന്റെ നടുവിൽ വെച്ചും Stop ഇപ്പോഴും അത് റദ്ദാക്കുന്നു.

കാരണം 3: ട്രേസിംഗ് ഓരോ കോളിന്റെയും ഇൻപുട്ടുകൾ സൂക്ഷിച്ചു

ഹീപ്പ് സ്നാപ്ഷോട്ട് മൂന്നാമത്തെ ഹോൾഡർ കാണിച്ചു: ഓരോ മോഡൽ കോളിനും ഏകദേശം 6 MB. ഇത് ഏജന്റ് ഫ്രെയിംവർക്കിന്റെ ഇവന്റ് സ്ട്രീമിംഗിൽ നിന്നായിരുന്നു. ടേണിലെ ഓരോ മോഡൽ കോളും ടേണിന്റെ child ആയി രേഖപ്പെടുത്തുന്നു, ഇൻപുട്ടുകളോടൊപ്പം, ടേൺ അവസാനിക്കുന്നതുവരെ. ഓരോ കോളിനും ഘടിപ്പിച്ച ഓരോ ചിത്രവും അതോടൊപ്പം മെമ്മറിയിൽ തങ്ങി.

പരിഹാരം: കോൾ തിരിച്ചുവന്നാലുടൻ ചിത്രങ്ങൾ ശൂന്യമാക്കുക

ചിത്രങ്ങൾ ഒരു പ്രത്യേക മോഡൽ കോളിനായി നിർമ്മിച്ച സന്ദേശങ്ങളിൽ മാത്രമേ ഘടിപ്പിക്കപ്പെടുന്നുള്ളൂ. അവ സംഭാഷണത്തിന്റെ സേവ് ചെയ്ത അവസ്ഥയിൽ ഒരിക്കലും സൂക്ഷിക്കപ്പെടുന്നില്ല. അതിനാൽ കോൾ തിരിച്ചെത്തിയ ശേഷം ആ സന്ദേശങ്ങളിലെ ചിത്ര ഡാറ്റ ശൂന്യമാക്കുന്നത് സുരക്ഷിതമാണ്. ട്രേസ് ആ കോളിന്റെ ടെക്സ്റ്റ് രേഖ സൂക്ഷിക്കുന്നു; പിക്സലുകൾ പോകുന്നു.

ഒരു വിശദാംശം പ്രധാനമായിരുന്നു: ചിത്രങ്ങൾ സ്ഥലത്തുതന്നെ ശൂന്യമാക്കണം. ട്രേസറിന് ഒരു സന്ദേശത്തിലെ ഒന്നിലധികം റഫറൻസുകളിലൂടെ ഒരേ ചിത്ര ഡാറ്റയിൽ എത്താം; പുതിയ ശൂന്യ ലിസ്റ്റ് വെച്ചാൽ യഥാർത്ഥ ലിസ്റ്റ്, പിക്സലുകളോടെ, ഇപ്പോഴും എത്തിച്ചേരാവുന്നതായി നിൽക്കും. സേവ് ചെയ്ത സംഭാഷണ അവസ്ഥ ഒരിക്കലും മാറ്റപ്പെടുന്നില്ല.

ഒരു ടെസ്റ്റ് ഏജന്റിന്റെ graph ഈ ഇവന്റ് സ്ട്രീമിംഗിന് കീഴിൽ പ്രവർത്തിപ്പിക്കുന്നു, ഓരോ കോളിലും 4 MB ചിത്രവുമായി. പരിഹാരമില്ലാതെ 16 കോളുകൾക്കിടയിൽ മെമ്മറി 77 MB വളർന്നു. പരിഹാരത്തോടെ മെമ്മറി സ്ഥിരമായി തുടരുന്നു.

ഞങ്ങൾ പഠിച്ചത്

• മെമ്മറി പ്രശ്നങ്ങൾ പാളികളായി വരാം. മൂന്ന് വ്യത്യസ്ത കാരണങ്ങൾ ഓരോന്നും ചിത്രങ്ങൾ അധികനേരം പിടിച്ചുവെച്ചു, ടേൺ മെമ്മറിക്കുള്ളിൽ നിൽക്കാൻ മൂന്നും നീക്കേണ്ടിവന്നു.
• ലൈബ്രറിക്ക് നൽകുന്നതെന്തും സൂക്ഷിക്കപ്പെട്ടേക്കാം. ഒരു signal-ഉം ഒരു ട്രേസും അവ നൽകിയ കോളുകളെക്കാൾ നീണ്ടുനിന്നു. ഓരോ കോളിലും മെമ്മറി വളരുമ്പോൾ, കോൾ തൊടുന്ന ദീർഘകാല വസ്തുക്കൾ എന്തൊക്കെയെന്ന് നോക്കുക.
• മറുവശം വലിച്ചെറിയുന്നത് അയക്കരുത്. മോഡൽ എന്തായാലും ഒഴിവാക്കുന്ന പിക്സലുകൾ ഓരോ കോളിലും ഞങ്ങൾക്ക് മെമ്മറി ചെലവാക്കി.
• മെമ്മറി നേരിട്ട് ടെസ്റ്റ് ചെയ്യുക. ഓരോ പരിഹാരത്തിനും ഹീപ്പ് വളർച്ചയോ listener എണ്ണമോ അളക്കുന്ന ഒരു ടെസ്റ്റ് ഉണ്ടായിരുന്നു, അതിനാൽ റിഗ്രഷൻ ഒരു ക്രാഷ് ആയല്ല, ഒരു സംഖ്യയായി കാണിക്കുന്നു.

ഏജന്റിൽ നിന്നുള്ള രണ്ടാമത്തെ മെമ്മറി കഥയാണിത്, ഒരു ചെറിയ കാലയളവിൽ. ആദ്യത്തേത് ഒരു പ്രോഗ്രസ് ലേബൽ 41,000 തവണ വീണ്ടും അയച്ചത് ആയിരുന്നു. ഏജന്റ് എന്താണെന്നും എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും അറിയണമെങ്കിൽ AI ഏജന്റുകൾ എന്ന ഗൈഡും ചാറ്റ് ഡോക്സും കാണുക.