Ajánlott eljárások és hibaelhárítási útmutató csomópontalkalmazásokhoz Azure-alkalmazás Service Windows rendszeren

Ebben a cikkben az ajánlott eljárásokat és hibaelhárítási lépéseket ismerheti meg az Azure-alkalmazás szolgáltatáson (iisnode)futó Windows Node.js-alkalmazásokhoz.

Figyelmeztetés

Körültekintően járjon el az éles telephely hibaelhárítási lépéseinek használatakor. Javasoljuk, hogy az alkalmazást ne éles környezetben, például az előkészítési ponton hárítsa el, és ha a probléma ki lett javítva, cserélje le az előkészítési pontot az éles ponttal.

IISNODE-konfiguráció

Ez a sémafájl az iisnode-hoz konfigurálható összes beállítást megjeleníti. Néhány, az alkalmazás számára hasznos beállítás:

nodeProcessCountPerApplication

Ez a beállítás szabályozza az IIS-alkalmazásonként indított csomópontfolyamatok számát. Az alapértelmezett érték 1. A virtuális gép vCPU-számához annyi node.exe fájlt indíthat el, ha az értéket 0-ra módosítja. Az ajánlott érték a legtöbb alkalmazás esetében 0, így az összes virtuális processzort használhatja a gépen. Node.exe egyszálas, így egy node.exe legfeljebb 1 vCPU-t használ fel. Ahhoz, hogy a csomópontalkalmazás maximális teljesítményt kapjon, az összes vCPU-t használnia kell.

nodeProcessCommandLine

Ez a beállítás szabályozza a node.exe elérési útját. Ezt az értéket úgy állíthatja be, hogy a node.exe verziójára mutasson.

maxConcurrentRequestsPerProcess

Ez a beállítás az iisnode által az egyes node.exe küldött egyidejű kérelmek maximális számát szabályozza. A Azure-alkalmazás szolgáltatásban az alapértelmezett érték a Végtelen. Az érték attól függően konfigurálható, hogy az alkalmazás hány kérést kap, és hogy milyen gyorsan dolgozza fel az alkalmazás az egyes kéréseket.

maxNamedPipeConnectionRetry

Ez a beállítás azt szabályozza, hogy az iisnode legfeljebb hányszor próbálkozik újra a névvel ellátott cső kapcsolatának létrehozásához, hogy a kéréseket elküldje node.exe. Ez a beállítás a NamedPipeConnectionRetryDelayrel kombinálva határozza meg az egyes kérések teljes időtúllépését az iisnode-on belül. Az alapértelmezett érték 200 a Azure-alkalmazás szolgáltatásban. Teljes időtúllépés másodpercben = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

namedPipeConnectionRetryDelay

Ez a beállítás szabályozza, hogy az iisnode mennyi időt vár az egyes újrapróbálkozások között, hogy a kérést a nevesített csőre node.exe küldje el. Az alapértelmezett érték 250 ms. Teljes időtúllépés másodpercben = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000

Alapértelmezés szerint az iisnode teljes időtúllépése Azure-alkalmazás szolgáltatásban 200 * 250 ms = 50 másodperc.

logDirectory

Ez a beállítás azt a könyvtárat szabályozza, ahol az iisnode naplók stdout/stderr. Az alapértelmezett érték az iisnode, amely a fő szkriptkönyvtárhoz (a fő server.js könyvtárhoz) viszonyítva van.

debuggerExtensionDll

Ez a beállítás szabályozza, hogy az iisnode csomópontfelügyelő melyik verzióját használja a csomópontalkalmazás hibakereséséhez. Jelenleg a iisnode-inspector-0.7.3.dll és a iisnode-inspector.dll az egyetlen érvényes érték ehhez a beállításhoz. Az alapértelmezett érték a iisnode-inspector-0.7.3.dll. A iisnode-inspector-0.7.3.dll-verzió a node-inspector-0.7.3-at használja, és webes szoftvercsatornákat használ. Engedélyezze a webes szoftvercsatornák használatát az Azure-webalkalmazásban ennek a verziónak a használatához.

flushResponse

Az IIS alapértelmezett viselkedése az, hogy a válaszadatokat akár 4 MB-ig puffereli a kiürítés előtt, vagy a válasz végéig, attól függően, hogy melyik az első. Az iisnode konfigurációs beállítást kínál a viselkedés felülbírálásához: ha az iisnode amint az iisnode megkapja a node.exe, a web.config iisnode/@flushResponse attribútumát "true" értékre kell állítania:

<configuration>
    <system.webServer>
        <!-- ... -->
        <iisnode flushResponse="true" />
    </system.webServer>
</configuration>

A válasz entitás törzsének minden töredékének kiürítése olyan teljesítményterhelést ad hozzá, amely ~5%-kal csökkenti a rendszer átviteli sebességét (a 0.1.13-as verziótól). A legjobb, ha ezt a beállítást csak válaszstreamelést igénylő végpontokra terjed ki (például a <location> web.config elem használatával)

Emellett a streamelési alkalmazások esetében az iisnode kezelőjének responseBufferLimit értékét is 0-ra kell állítania.

<handlers>
    <add name="iisnode" path="app.js" verb="\*" modules="iisnode" responseBufferLimit="0"/>
</handlers>

watchedFiles

A módosításokra figyelt fájlok pontosvesszővel tagolt listája. A fájl bármely módosítása miatt az alkalmazás újrafeldolgozható. Minden bejegyzés egy választható könyvtárnévből és egy szükséges fájlnévből áll, amely ahhoz a könyvtárhoz képest van, ahol a fő alkalmazás belépési pontja található. A helyettesítő kártyák csak a fájlnévrészben engedélyezettek. Az alapértelmezett érték a következő: *.js;iisnode.yml

recycleSignalEnabled

Az alapértelmezett érték: hamis. Ha engedélyezve van, a csomópontalkalmazás csatlakozhat egy elnevezett csőhöz (IISNODE_CONTROL_PIPE környezeti változóhoz), és küldhet egy "lomtár" üzenetet. Ez azt eredményezi, hogy a w3wp kecsesen újrahasznosítható.

idlePageOutTimePeriod

Az alapértelmezett érték 0, ami azt jelenti, hogy ez a funkció le van tiltva. Ha 0-nál nagyobb értékre van állítva, az iisnode ezredmásodpercben megjeleníti az összes gyermekfolyamatát minden "idlePageOutTimePeriod"-ban. Tekintse meg a dokumentációt , amelyből megtudhatja, hogy mit jelent a lapeltárás. Ez a beállítás olyan alkalmazások esetében hasznos, amelyek nagy mennyiségű memóriát használnak fel, és időnként ki szeretnék emelni a memóriát a lemezre, hogy felszabadítsa a RAM-ot.

Figyelmeztetés

Az éles alkalmazásokban a következő konfigurációs beállítások engedélyezésekor körültekintően járjon el. A javaslat az, hogy ne engedélyezze őket élő éles alkalmazásokban.

debugHeaderEnabled

Az alapértelmezett érték: hamis. Ha igaz értékre van állítva, az iisnode egy HTTP-válaszfejlécet iisnode-debug ad hozzá minden olyan HTTP-válaszhoz, amelyet a iisnode-debug fejléc értéke egy URL-cím. Az EGYES diagnosztikai információk az URL-töredék vizsgálatával szerezhetők be, azonban vizualizáció érhető el az URL böngészőben való megnyitásával.

loggingEnabled

Ez a beállítás szabályozza a stdout és a stderr iisnode általi naplózását. Az Iisnode rögzíti a stdout/stderrt az általa indított csomópontfolyamatokból, és a logDirectory beállításban megadott könyvtárba ír. Ha ez engedélyezve van, az alkalmazás naplókat ír a fájlrendszerbe, és az alkalmazás által végzett naplózás mennyiségétől függően teljesítménybeli következményekkel járhat.

devErrorsEnabled

Az alapértelmezett érték: hamis. Ha igaz értékre van állítva, az iisnode megjeleníti a HTTP-állapotkódot és a Win32 hibakódot a böngészőben. A win32-kód hasznos bizonyos típusú problémák hibakeresésében.

debuggingEnabled (élő éles környezetben nem engedélyezett)

Ez a beállítás szabályozza a hibakeresési funkciót. Az Iisnode integrálva van a csomópontfelügyelővel. A beállítás engedélyezésével engedélyezheti a csomópontalkalmazás hibakeresését. A beállítás engedélyezésekor az iisnode csomópontfelügyelő fájlokat hoz létre a "debuggerVirtualDir" könyvtárban a csomópontalkalmazás első hibakeresési kérésén. A csomópontfelügyelőt egy kérés http://yoursite/server.js/debugelküldésével töltheti be. A hibakeresési URL-szegmenst a "debuggerPathSegment" beállítással szabályozhatja. Alapértelmezés szerint debuggerPathSegment='debug'. debuggerPathSegment Beállíthatja például a GUID-t, hogy mások nehezebben tudják felderíteni.

A hibakereséssel kapcsolatos további részletekért olvassa el a Hibakeresési Node.js-alkalmazásokat Windows rendszeren.

Forgatókönyvek és javaslatok/hibaelhárítás

A csomópontalkalmazás túl sok kimenő hívást indít

Sok alkalmazás a normál működése részeként szeretne kimenő kapcsolatokat létesíteni. Ha például érkezik egy kérés, a csomópontalkalmazás szeretne kapcsolatba lépni egy REST API-val máshol, és le szeretne kérni néhány információt a kérés feldolgozásához. Http- vagy https-hívások esetén érdemes egy életben tartási ügynököt használni. Ezeket a kimenő hívásokat az agentkeepalive modult használhatja az életben maradó ügynökként.

Az agentkeepalive modul biztosítja, hogy a szoftvercsatornák újra felhasználhatók legyenek az Azure webapp virtuális gépen. Ha minden kimenő kérelemhez új szoftvercsatornát hoz létre, azzal többletterhelést okoz az alkalmazásnak. Ha az alkalmazás újra felhasználja a szoftvercsatornákat a kimenő kérelmekhez, az biztosítja, hogy az alkalmazás ne lépje túl a virtuális gépenként lefoglalt maxSocketeket. A Azure-alkalmazás szolgáltatásra vonatkozó javaslat az, hogy az agentKeepAlive maxSockets értékét virtuális gépenként összesen (4 node.exe * 32 maxSockets/instance) 128 szoftvercsatornára állítsa.

Példa agentKeepALive konfigurációra:

let keepaliveAgent = new Agent({
    maxSockets: 32,
    maxFreeSockets: 10,
    timeout: 60000,
    freeSocketTimeout: 300000
});

Fontos

Ez a példa feltételezi, hogy 4 node.exe fut a virtuális gépen. Ha a virtuális gépen eltérő számú node.exe fut, ennek megfelelően módosítania kell a maxSockets beállítást.

A csomópontalkalmazás túl sok processzort használ fel

A portálon a Azure-alkalmazás Szolgáltatás ajánlást kaphat a magas processzorhasználatról. Monitorokat is beállíthat bizonyos metrikák figyelésére. Amikor az Azure Portal irányítópultján ellenőrzi a processzorhasználatot, ellenőrizze a PROCESSZOR MAX-értékeit, hogy ne hagyja ki a csúcsértékeket. Ha úgy véli, hogy az alkalmazás túl sok processzort használ, és nem tudja elmagyarázni, hogy miért, profilt készíthet a csomópontalkalmazásról, hogy megtudja.

Csomópontalkalmazás profilozása a Azure-alkalmazás Szolgáltatásban a V8-Profilerrel

Tegyük fel például, hogy rendelkezik egy hello world alkalmazással, amelyet a következőképpen szeretne profilba venni:

const http = require('http');
function WriteConsoleLog() {
    for(let i=0;i<99999;++i) {
        console.log('hello world');
    }
}

function HandleRequest() {
    WriteConsoleLog();
}

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    HandleRequest();
    res.end('Hello world!');
}).listen(process.env.PORT);

Ugrás a Hibakeresési konzol webhelyre https://yoursite.scm.azurewebsites.net/DebugConsole

Lépjen a webhelyre/wwwroot könyvtárba. A parancssor az alábbi példában látható módon jelenik meg:

Futtassa a következő parancsot: npm install v8-profiler.

Ez a parancs telepíti a v8-profilozót node_modules könyvtár és annak összes függősége alatt. Most szerkessze a server.js az alkalmazás profilkészítéséhez.

const http = require('http');
const profiler = require('v8-profiler');
const fs = require('fs');

function WriteConsoleLog() {
    for(let i=0;i<99999;++i) {
        console.log('hello world');
    }
}

function HandleRequest() {
    profiler.startProfiling('HandleRequest');
    WriteConsoleLog();
    fs.writeFileSync('profile.cpuprofile', JSON.stringify(profiler.stopProfiling('HandleRequest')));
}

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    HandleRequest();
    res.end('Hello world!');
}).listen(process.env.PORT);

Az előző kód profilja a WriteConsoleLog függvény, majd a profil kimenetét a webhely wwwroot alatti "profile.cpuprofile" fájljába írja. Küldjön egy kérést az alkalmazásnak. Megjelenik egy "profile.cpuprofile" fájl, amelyet a webhelye wwwroot alatt hozott létre.

Töltse le ezt a fájlt, és nyissa meg a Chrome F12 Tools használatával. Nyomja le az F12 billentyűt a Chrome-on, majd válassza a Profilok lapot. Válassza a Betöltés gombot. Válassza ki a letöltött profile.cpuprofile fájlt. Kattintson az imént betöltött profilra.

Láthatja, hogy a WriteConsoleLog függvény az idő 95%-át felhasználta. A kimenet a problémát okozó pontos sorszámokat és forrásfájlokat is megjeleníti.

A csomópontalkalmazás túl sok memóriát használ fel

Ha az alkalmazás túl sok memóriát használ fel, a portálon megjelenik egy értesítés a Azure-alkalmazás Szolgáltatástól a magas memóriahasználatról. Beállíthat monitorokat bizonyos metrikák figyelésére. Amikor az Azure Portal irányítópultján ellenőrzi a memóriahasználatot, ellenőrizze a memória MAX-értékeit, hogy ne maradjon le a csúcsértékről.

Szivárgásészlelés és halom diff Node.js

A node-memwatch segítségével azonosíthatja a memóriavesztéseket. A v8-profilozóhoz hasonlóan telepítheti memwatch a kódot, és szerkesztheti a kódját a halmok rögzítéséhez és terjesztéséhez az alkalmazás memóriavesztéseinek azonosításához.

A node.exe véletlenszerűen ölik meg.

Van néhány oka annak, hogy node.exe véletlenszerűen leáll:

1. Az alkalmazás nem használt kivételeket ad ki – Ellenőrizze a d:\home\LogFiles\Application\logging-errors.txt fájlt a kidobott kivétel részleteiért. Ez a fájl rendelkezik a verem nyomkövetésével az alkalmazás hibakereséséhez és javításához.
2. Az alkalmazás túl sok memóriát használ fel, ami más folyamatokat is érint az első lépésektől kezdve. Ha a virtuális gép teljes memóriája megközelíti a 100%-ot, a node.exe a folyamatkezelő ölheti meg. A Folyamatkezelő megöl néhány folyamatot, hogy más folyamatok is elvégezhessenek némi munkát. A probléma megoldásához profilozza az alkalmazást a memóriaszivárgások miatt. Ha az alkalmazás nagy mennyiségű memóriát igényel, skálázhat fel egy nagyobb virtuális gépre (ami növeli a virtuális gép számára elérhető RAM-ot).

A csomópontalkalmazás nem indul el

Ha az alkalmazás az indításkor 500 hibát ad vissza, annak több oka is lehet:

1. Node.exe nincs a megfelelő helyen. Ellenőrizze a nodeProcessCommandLine beállítást.
2. A fő szkriptfájl nincs a megfelelő helyen. Ellenőrizze a web.config fájlt, és győződjön meg arról, hogy a kezelő szakaszban lévő fő szkriptfájl neve megegyezik a fő szkriptfájléval.
3. A Web.config konfigurációja nem helyes – ellenőrizze a beállítások nevét/értékeit.
4. Hidegindítás – Az alkalmazás indítása túl sokáig tart. Ha az alkalmazás hosszabb időt vesz igénybe, mint (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000 másodperc, az iisnode 500-es hibát ad vissza. Növelje ezeknek a beállításoknak az értékeit az alkalmazás kezdési időpontjának megfelelően, hogy megakadályozza az iisnode időtúllépését és az 500-ás hiba visszaadását.

Összeomlott a csomópontalkalmazásom

Az alkalmazás nem használt kivételeket ad ki – Ellenőrizze d:\\home\\LogFiles\\Application\\logging-errors.txt a kidobott kivétel részleteit tartalmazó fájlt. Ez a fájl rendelkezik a verem nyomkövetésével az alkalmazás diagnosztizálásához és javításához.

A csomópontalkalmazás indítása túl sok időt vesz igénybe (hidegindítás)

A hosszú alkalmazásindítási idők gyakori oka a node_modules lévő fájlok nagy száma. Az alkalmazás az indításkor megpróbálja betölteni a fájlok többségét. Alapértelmezés szerint, mivel a fájlok a Azure-alkalmazás szolgáltatás hálózati megosztásán vannak tárolva, sok fájl betöltése időigényes lehet. A folyamat felgyorsítására néhány megoldás a következő:

1. Próbálja meg lusta betölteni a node_modules, és ne töltse be az összes modult az alkalmazás indításakor. A lusta betöltési modulok esetében a követelmény(eke)t akkor kell meghívni, ha ténylegesen szüksége van a modulra a függvényen belül a modulkód első végrehajtása előtt.
2. Azure-alkalmazás szolgáltatás egy helyi gyorsítótár nevű funkciót kínál. Ez a funkció átmásolja a tartalmat a hálózati megosztásból a virtuális gép helyi lemezére. Mivel a fájlok helyiek, a node_modules betöltési ideje sokkal gyorsabb.

IISNODE http állapota és alállapota

A cnodeconstants forrásfájl felsorolja az összes lehetséges állapot-/alállapot-kombinációt, amely az iisnode hiba miatt vissza tud térni.

Engedélyezze a FREB-t az alkalmazás számára a win32 hibakód megtekintéséhez (győződjön meg arról, hogy a FREB-t csak nem éles helyeken engedélyezi teljesítmény okokból).

Http-állapot	Http-alállapot	Lehetséges ok?
500	1000	Probléma lépett fel a kérésnek az IISNODE-be való elküldésével – Ellenőrizze, hogy node.exe elindult-e. Node.exe az indításkor összeomolhatott volna. Ellenőrizze a web.config konfigurációjának hibáit.
500	1001	- Win32Error 0x2 – Az alkalmazás nem válaszol az URL-címre. Ellenőrizze az URL-átírási szabályokat, vagy ellenőrizze, hogy az expressz alkalmazás rendelkezik-e a megfelelő útvonalakkal. - Win32Error 0x6d – a nevesített cső foglalt – Node.exe nem fogadja el a kéréseket, mert a cső foglalt. Ellenőrizze a magas processzorhasználatot. – Egyéb hibák – ellenőrizze, hogy node.exe összeomlott-e.
500	1002	Node.exe összeomlott – ellenőrizze a d:\home\LogFiles\logging-errors.txt veremkövetést.
500	1003	Csőkonfigurációs probléma – A megnevezett csőkonfiguráció helytelen.
500	1004-1018	Hiba történt a kérés elküldése vagy a válasz feldolgozása közben node.exe. Ellenőrizze, hogy node.exe összeomlott-e. ellenőrizze a d:\home\LogFiles\logging-errors.txt veremkövetést.
503	1000	Nincs elég memória több elnevezett csőkapcsolat lefoglalásához. Ellenőrizze, hogy az alkalmazás miért használ fel ilyen sok memóriát. Ellenőrizze a maxConcurrentRequestsPerProcess beállítás értékét. Ha nem végtelen, és sok kérése van, növelje ezt az értéket a hiba elkerülése érdekében.
503	1001	A kérés nem küldhető el node.exe, mert az alkalmazás újrahasznosításra kerül. Az alkalmazás újrafeldolgozása után a kérelmeket a szokásos módon kell kézbesíteni.
503	1002	Ellenőrizze, hogy a win32 hibakódja valós okból nem küldhető-e el egy node.exe.
503	1003	A nevesített cső túl elfoglalt – Ellenőrizze, hogy node.exe túlzott processzorhasználatot használ-e

NODE.exe egy .NODE_PENDING_PIPE_INSTANCES A Azure-alkalmazás szolgáltatásban ez az érték 5000. Ez azt jelenti, hogy node.exe egyszerre 5000 kérést fogadhat el a megnevezett csőre. Ennek az értéknek elég jónak kell lennie a Azure-alkalmazás Szolgáltatáson futó csomópontalkalmazások többségéhez. Az 503.1003 nem jelenik meg a Azure-alkalmazás szolgáltatásban, mert aNODE_PENDING_PIPE_INSTANCES

További erőforrások

Az alábbi hivatkozásokra kattintva további információt talál Node.js alkalmazásokról a Azure-alkalmazás Szolgáltatásban.

• Ismerkedés a Node.js-webalkalmazásokkal az Azure App Service-ben
• A Node.js webalkalmazás hibakeresése az Azure App Service-ben
• A Node.js modulok használata az Azure alkalmazásokkal
• Azure App Service Web Apps: Node.js
• Node.js fejlesztői központ
• A Szupertitkos Kudu hibakereső konzol felfedezése