És lent 3 GB RAM?

Estem provant Solarwinds NPM(10.3) i SAM. El sistema és un servidor de formatat recentment Windows 2003 SP2 amb un processador de doble nucli Xeon amb 2 GB (inicialment, que s' ha actualitzat a 3 GB) i 200GB HDD lliure. Estem usant el servidor SQL incorporat i es canviarà a un servidor de bases de dades dedicat una vegada que decidim obtenir els solarwinds. Només s' han afegit 3 nodes (v interfícies de 11). Des del primer dia, ens hem adonat que el rendiment de la consola web és molt lent i que l'ús de la RAM del sistema és a prop de 1,8 GB. Hem augmentat la RAM a 3GB, però el rendiment de consola web encara és lent. Hi ha vegades que la consola no carrega gens. Si reengegam els serveis, la consola funciona bé durant un temps abans que el problema torni a aparèixer. El punt d' acabament Symantec està instal· lat al servidor, però s' atura des que pensàvem que podria estar causant un problema però el rendiment no millora. També volíem provar els components NTA i NCM però no s'han instal·lat perquè aquest problema podria ser pitjor. Alguna idea per què pot ser un problema?

Preferiblement, quin seria el requisit de la RAM si volem provar tots els components? Per al POC inicial simplement afegiríem 5 encaminadors(1 executant flux net) i 3 servidors. M'imagino que el servidor que estem proporcionant és prou decent per a la POC abans de decidir anar a una configuració completament perduda.

Vaig entrar en aquest tema i la implementació tècnica em va dir que era perquè estava corrent SQL al nostre servidor d'Orió. Van dir que podríem veure una millora un cop la vam traslladar. Encara no ho hem fet, però he parlat amb un parell d'altres persones que han tingut el mateix problema i han dit que s'han aixecat els seus sistemes. Bona sort.

També hem experimentat exactament el mateix que vostè descriu. Tenim el nostre servidor d'Orió i el servidor SQL separats per no assegurar-nos de quin problema està malgrat les recomanacions del Solarwinds que els col·locaran en servidors separats augmentaria l'actuació. També estem executant-nos en un entorn d'empresa amb centenars de servidors, encaminadors i interruptors, així que no sabem si estem sobrecarregant l'enquesta d'alguna manera. Tenim la quantitat màxima de RAM en ambdós servidors però tot i així la interfície web es mou a un ritme de cargols. No obstant això, estem planejant una actualització a un SO de 64 bits amb almenys 16 Gb de la RAM per tal que el OSM i la RAM addicional facin una diferència.

Potser també voleu limitar la quantitat de la RAM SQL. SQL portarà la RAM fins que es mori de fam la resta del servidor (eines de gestió de l'Open SQL, propietats del servidor, Memòria, establert MAX - el més alt és, el temps menys disc, però més es mor de fam d' altres aplicacions, heu de trobar un bon equilibri)

Nosaltres també tenim problemes d'aquesta naturalesa i hem estat des de fa molt de temps. Hem llançat quantitats no realistes de maquinari a la nostra instal·lació de consola, hem carregat SQL a una caixa dedicada, i encara tenim un terrible rendiment de consola web. Fa poc que vam utilitzar Wireshark i vam identificar els problemes de la finestra del temps zero (per a mi és el terme no és correcte, els nois de xarxa el van trobar). M'han dit que això té a veure amb la pila TCP.

No estic segur si estic al lloc correcte o no, però estic en les propietats del servidor tal com heu declarat i a la secció de memòria, però els arranjaments semblen apagats. El servidor només té 4 Gb de memòria, però el màxim està establert a 2147483647, que és a Mb. El mínim està establert a 0 i s' arranja per usar l' objectiu d' assignar memòria. No sóc cap mestre SQL i no vull canviar això a menys que recomanat fer-ho d'una altra manera. Però ja no vull alentir-lo més que el que ja és. També la nostra base de dades SQL és en un servidor que normalment utilitzem per a una màquina de captura de dades per tal que aquesta sigui l'única cosa en la meva ment que hauria de competir per a una altra memòria que les finestres normals succeeixin.

Aquest és el lloc - SQL està configurat just fora de la caixa per consumir tant memòria com pugui ( 2147483647 - 2 PB, home a qui voldria poder permetre'm servidors amb aquesta gran RAM! Però he trobat això per causar problemes que es moren de gana amb l' SO subjacent. Us suggeriria que establiu la RAM a 3 *1024=3072 per deixar 1gb per l' OSM i només usareu aquest servidor per SQL (no sé què voleu dir amb " captura de dades," però si això consumeix temps de memòria o discs, aquest podria ser el problema de SQL, és clar, si s' executa durant 5 minuts al dia, i no us importa si hi ha una mica de retard en aquest moment, llavors no importa). Faig servir el 2008 R2 Core perquè protegeix la gent de TS-ing cap al servidor i començant un munt d' eines que podrien/ haurien d' estar usant des del seu escriptori per a gestionar el servidor remotament.

Aquells dies eren 2GB de la RAM ha passat molt de temps i han marxat. Necessiteu molt més del 2GB considerant que és un sistema de monitorització i també considerant que SQL està instal· lat i que s' està executant al mateix servidor. Aquests dos rols mai estaran inactius al servidor.

Necessitareu un mínim de 4GB per a una prova en la que tot funcioni amb calma. Tingueu present que si el vostre sistema operatiu no és de 64 bits, no sereu capaços d' adreçar més de 3. 5GB de memòria global del sistema.

Encara més important és el tipus de discs utilitzat en aquest servidor. Des que Orió és una aplicació basada en web, necessitareu emmagatzemar que sigui capaç de proporcionar les demandes IOP que requereix un servidor web (rrutura del polze) i fins i tot més alt exigeix que un servidor SQL tingui en termes d'IOP (també regla del polze).

El nombre de discs i tipus RAID són clau per a una aplicació web ben realitzant un servidor web/SQL. Suposo que esteu utilitzant ARID pels discs, si és així, l'RAID 1 i l'RAID 5 generalment es consideren com a tipus d'RAID web/SQL. Quan inverteixis a Orió com a sistema NMS, necessitaràs ARID 10 (RAID 1+0) per a que tot funcioni suau. L' SQL preferiria estar executant- se en un servidor dedicat.

Amb atenció a SQL i la memòria, agafa el consell de netloxs a l'ús de memòria límit. Un bon lloc per començar seria limitar la memòria SQL al 70% de la memòria del sistema.

Així que si teniu 3GB de memòria en el sistema hauríeu de limitar SQL a utilitzar el 2150MB. Això deixa 920MB o així la memòria de l'OSM, l'aplicació i el servidor web -- i això no és gaire! Podria limitar l'ús de memòria SQL a sota del 70% però llavors SQL patiria i notarà problemes de rendiment amb un accés web lent, també.