none
risorse appesantite da database su Win Server 2008 Foundation RRS feed

  • Discussione generale

  • Su un paio di installazioni mi è capitata una problematica identica: i gestionali in rete si appesantiscono a dismisura come se sul server si accumulassero file temporanei e cache a supporto del database.

    In entrambi i casi si tratta di un normale database .mdb su server e nessun gestore, è tutto gestito dai client che accedono usano il server esclusivamente come file server.

    Il problema si risolve riavviando il server, ma alcune operazioni più pesanti sui gestionali tendono a ricrearlo in pochi minuti, ed escluderei la responsabilità dei gestionali visto che è successo con diversi sw e l'unica costante è il tipo di server e S.O. installato su di esso. La macchina è recente, ha 8Gb di ram e giusto 4 client collegati, alcuni non usano nemmeno i gestionali.

    Poichè usando come server un comune Win 7 pro o similare il problema non si verifica, chiedo se su Win Server ci possono essere servizi attivi che il sistema cerca di mettere a supporto del database, o che cercano di vigilare sul traffico producendo dati che intasano ram e disco, perchè vorrei provare a disattivarli.

    Tempo fa su queste installazioni provai ad interrompere dei processi che utilizzavano molta ram e sentii che anche il disco lavorò un buon minuto per svuotare una quantità di dati accumulati in coda, i gestionali ripresero velocità come dopo un riavvio, purtroppo non ricordo il nome del processo tuttavia mi fa pensare ad un servizio attivo per sostenere i database in rete che però non fa altro che occupare tutte le risorse del server e finisce per rallentare il lavoro dei client.

    Se qualcuno ha presente quale possa essere la problematica o ci si è già imbattuto per favore faccia sapere cosa potrei disattivare, grazie.

    martedì 28 giugno 2016 09:41

Tutte le risposte

  • Ciao, be' la domanda andrebbe fatta a chi fornisce il gestionale e che lo da compatibile con 2008 foundation, non sul forum windows server.. Foundation è un sistema abbastanza leggero e nonostante abbia praticamente tutte le feature dei fratelli più grandi non è un sistema per far girare applicativi pesanti. Ritorniamo sempre al punto sopra, pesante che vuol dire? Gestionali ne vedo a frotte su sistemi di ogni tipo, i rallentamenti sono sempre dati dalle poche risorse macchina, di solito ram, processore, ma in alcuni casi anche le velocità dei dischi, sono però sempre le case madri che producono il SW a doverti dire dove sta il problema, lato sistema operativo puoi solo andare a tentoni e non è una soluzione. Il problema comunque non è mai in nessun caso il sistema di base, è come l'applicativo lo sfrutta e nessuno al di fuori di chi lo produce può metterci una "pezza".

    La tua domanda quindi è troppo generica, è come dire "ho il server lento", può avere mille soluzioni diverse e poi magari è un sistema non completamente supportato dal SW in questione..chissà? 

    Ciao.

    A.

    martedì 28 giugno 2016 14:53
    Moderatore
  • Si tratta in entrambi i casi di sw realizzati da produttori locali che interpellati hanno confermato che il database non ha bisogno di alcun gestore su server, semplicemente il server viene usato come disco di rete dove parcheggiare i file comuni. Fanno tutto i client che hanno il loro gestore db integrato, quando interrogano il server da remoto.

    Ma come detto il problema avviene solo su queste macchine con S.O. server, dove hanno adottato un Win7 pro come file server i rallentamenti non avvengono, ma i produttori dicono che non c'è alcuna controindicazione nell'usare un S.O. Server, proprio perchè basta che il file database sia su un disco condiviso in rete, potrebbe essere anche un qualsiasi Nas.

    Il problema è proprio che due gestionali di produttori diversi, ma simili nella tipologia di database, siano lenti soltanto su due server uguali con S.O. Win Server 2008; ne consegue che il sistema debba avere un qualche servizio attivo che interviene nel tentativo di supportare il database o di gestire il traffico dai client, magari un componente VB o qualcosa del genere pensato per supportare piattaforme più sofisticate.

    Parliamo comunque di macchine server recenti e di database sotto i 200mb, con non più di 3-4 client collegati al gestionale, non certo il peso da inginocchiare un sistema del genere.

    Comprendo la genericità della domanda ma visto che a me è capitato già 2 volte suppongo anche che altri si siano imbattuti nel problema che è ben riconoscibile quando quel genere di gestionali sono installati in rete con questi server.

    mercoledì 29 giugno 2016 06:22
  • vedi, già il fatto che vengano sviluppati da produttori locali vuol dire che non hanno quasi sicuramente la certificazione del sw su server MS per i vari sistemi, perché costa parecchio, se quindi i loro sw sotto foundation hanno quel tipo di problema perché magari usano parti di sistema che nello standard non usano si e no che lo sanno. Un SW gestionale va certificato sulla piattaforma, per farlo la SW House deve eseguire i test sulle varie release e pagare fior di quattrini per avere il poi il patacchino che ne certifica il funzionamento su quella versione, se non ce l'ha possiamo stare qui fino al 2020 a cercare soluzioni che non troveremo, se ce l'ha vuol dire che ha già risolto questi problemi ed in caso non l'abbia fatto può rivolgersi a MS per farsi aiutare, ma non devi farlo tu e qui noi non siamo di MS quindi ti rinnovo il discorso: hai preso la palla dalla parte sbagliata, non sei tu a dover cercare la soluzione, è la sw house.

    Ciao.

    A.

    mercoledì 29 giugno 2016 08:18
    Moderatore
  • Probabilmente è così, ma parliamo di gestionali sofisticati e non di prodotti fatti in casa, e visto che su un pc normale usato come server funzionano, mentre hanno problemi su un server nuovo, è lecito che il cliente chieda una soluzione a chi fornisce il server, specie se le sw house si rifiutano di ammettere responsabilità.

    Ci tengo a precisare che anche su altri server con Windows Server in altre versioni (non 2008 foundation) queste applicazioni non hanno problemi, quindi si tratta di trovare la discriminante che è più a sfavore del server che del gestionale.

    Microsoft dispone di un elenco dei servizi di rete presenti in un server 2008 Foundation rispetto ad una macchina client o altri S.O. Win Server precedenti? Ammesso anche che il gestionale abbia la sua parte di responsabilità, non è possibile individuare quale potrebbe essere su server il processo responsabile di questo problema che su un Windows 7 non si verifica? Faccio presente che su server non c'è altro che qualche file .mdb condiviso in rete.


    • Modificato Pilloso giovedì 30 giugno 2016 07:48
    giovedì 30 giugno 2016 07:29
  • Non esiste un elenco di servizi differenti sulle versioni server. torniamo sempre al punto base, se alla SW house interessa che il loro gestionale giri su Foundation prendono in mano la palla se no non lo certificano per Foundation. Lato Windows nessuno te la prenderà in carico, soprattutto su un forum gratuito perché noi non siamo la MS, qui si parla di debug su terze parti e gratis il debug..tra le altre cose bisognerebbe avere lo stesso applicativo su un server e non hai nemmeno citato i nomi..quindi. Spero che sia chiaro stavolta.

    Ciao.

    A.

    giovedì 30 giugno 2016 09:29
    Moderatore
  • Chiarissimo per me, mai pretesa la soluzione dal forum, seppure in genere sia abituato a trovare risposte tipo "potresti provare a...".

    Ovviamente il cliente chiederà cosa dovrebbe avere Foundation di diverso da atri Win Server, e chiederà la sostituzione con qualcosa che potrebbe essere anche Linux, d'altronde se nessuno vuole risolvere tocca a noi tecnici, questa è la triste realtà delle aziende che non possono fermarsi a guardare noi installatori che ci scarichiamo le colpe.

    Grazie, Saluti.


    • Modificato Pilloso venerdì 1 luglio 2016 06:16
    venerdì 1 luglio 2016 06:05
  • Diciamo che già la soluzione di utilizzare file .mdb su condivisioni smb invece di un vero database come SQL Server o MySQL non è particolarmente efficiente....

    Windows 7 e Server 2008 R2 sono in pratica lo stesso sistema operativo sotto questo punto di vista, con la differenza che la versione Server non ha limitazioni di connessioni. Quindi per assurdo questa limitazione potrebbe rendere "efficiente" il software, che magari non gestisce molto bene l'apertura di connessioni di rete (ad esempio rimangono delle connessioni aperte che saturano le risorse, ecc..). Se invece parli di Server 2008 (non R2), allora viene utilizzato il protocollo SMB 2.0 invece del 2.1, quindi magari potrebbe dipendere anche da questa differenza.

    https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/

    Quindi qui in realtà non si tratta tanto di scaricare di colpe ma di capire esattamente cosa fa il software e in che modo, per questo il servizio di assistenza della software house potrebbe darti sicuramente indicazioni più precise sulle possibili cause dei rallentamenti. Se l'azienda però non certifica il funzionamento del gestionale su quella versione di Windows Server sicuramente la cosa migliore è passare direttamente ad un sistema operativo che è dichiarato supportato.

    PS: Vedi anche se ti trovi in questo scenario:

    https://support.microsoft.com/en-us/kb/976618

    venerdì 1 luglio 2016 08:38
    Moderatore
  • Chiarissimo per me, mai pretesa la soluzione dal forum, seppure in genere sia abituato a trovare risposte tipo "potresti provare a...".

    Ovviamente il cliente chiederà cosa dovrebbe avere Foundation di diverso da atri Win Server, e chiederà la sostituzione con qualcosa che potrebbe essere anche Linux, d'altronde se nessuno vuole risolvere tocca a noi tecnici, questa è la triste realtà delle aziende che non possono fermarsi a guardare noi installatori che ci scarichiamo le colpe.

    Grazie, Saluti.


    In realtà è molto chiaro anche per il cliente:

    - lui compra un hardware ed un sistema che la sw house gli certifica

    funziona? bene. non funziona? problema della sw house. Il problema è quando il sistemista di turno gli offre un sistema che lui pensa funzioni senza avere testato il sw su di esso o senza aver contattato la sw house, in quel caso (magari non è il tuo) la colpa è solamente del sistemista ed il cliente dovrebbe saperlo. Il sw guida sempre la macchina, basta seguire le loro indicazioni, se poi rispondono "boh" alle problematiche il cliente se la gioca con loro ed il sistemista è fuori dai giochi. Questo è l'unico modo corretto di dare una piattaforma per un gestionale a chiunque, così non devi tu correre ai ripari se qualcosa non va e se lo fai lo fai solo guadagnando punti sul cliente a favore della sw house.

    Ciao.

    A.

    venerdì 1 luglio 2016 09:54
    Moderatore
  • Salve a tutti,

    ero sparito semplicemente per fare verifiche con la collaborazione del programmatore del gestionale che ha dato piena disponibilità, sono emersi alcuni dettagli che spostano la responsabilità su alcuni client, anche se finiamo un po' OT, credo sia giusto puntualizzare per chiudere il thread e casomai aveste nuovi suggerimenti in merito saranno assai graditi.

    Ho provato anche la patch per ottimizzare la cache del server linkata da Fabrizio Giammarini con le impostazioni di default ma purtroppo non ha dato esiti.

    Ciò che è emerso è che sui 4 client (Tutti Windows 10 pro) soltanto due producono grossi rallentamenti, e sono proprio le due macchine più nuove, tra l'altro piuttosto performanti ed anche molto "in ordine" come software installati. I rallentamenti sono semplicemenente su delle query di interrogazione del database che se effettuate la prima volta appena entrati nel gestionale sono talmente lente da paralizzare l'applicazione per oltre 1 minuto, se poi vengono effettuate nuovamente dalla seconda volta in poi mostrano il risultato in pochi secondi, forse anche perchè il client Windows supporta l'operazione con la sua cache.

    Gli altri 2 client Win 10 su cui tutto funziona regolarmente sono aggiornamenti dal precedente Windows 7 (uno è anche 32 bit), evidentemente qualche differenza c'è ma non abbiamo idea di quale possa essere.

    Ho installato per prova anche un vecchio pc con Win XP e salvo qualche ritardo di pochi secondi giustificato dalla macchina datata, sulle pratiche che mettono in scacco le macchine nuove, non ha fatto riscontrare alcun problema ed effettua tutto in tempi accettabili.

    Questo ovviamente solleva da responsabilità sia il server che il gestionale, tuttavia la sposta sui nuovi Windows 10 che devono per forza avere qualcosa di differente, suppongo tra i servizi di rete o qualcosa di simile. Vi risulta che servizi come Samba o similari possano influire, o che ci sia altro di specifico da verificare/ disattivare per poter fare ulteriori test?

    Vi ringrazio ancora per l'aiuto, saluti.

    venerdì 23 settembre 2016 09:04

  • Questo ovviamente solleva da responsabilità sia il server che il gestionale, tuttavia la sposta sui nuovi Windows 10 

    ma anche no. Scusa, a mio parere il problema è e resta del gestionale non ottimizzato per i windows 10.

    Ma te lo certificano? se te lo certificano sanno dove mettere le mani perchè hanno debuggato, se non te lo certificano ed hai dei W10 i problemi sono tuoi non del gestionale. E' semplice da comprendere, cristallino direi. 

    Per il CAD è la stessa cosa, il programma guida la scelta: serve una Workstation con 16GB di ram, disco SSD e processore Xeon e windows 7 perchè 10 non è ancora testato. Benissimo. Ci metti 10? il problema è tuo. Capisci che non possiamo trovare lato sistemistico una soluzione a qualcosa che chi ha creato non ha idea dove intervenire? Se tu dovessi pagare realmente un sistemista che ti sta in azienda delle giornate a cercare una soluzione credo non lo faresti no? 

    :-) ogni giorno mi scontro con programmatori e sw house che non fanno debug sui nuovi sistemi e "passano la palla" al sistemista di turno che deve trovare una soluzione a qualcosa che non gli compete. E' per questo che ho il dente un po avvelenato. Programmatori, vendete il sw dopo che l'avete testato per bene sulle piattaforme e sapete come intervenire ad occhi chiusi quando qualcosa non va, sarebbe la volte che un sw funziona ;-).

    Ciao.

    A.

    venerdì 23 settembre 2016 14:30
    Moderatore
  • Sarà difficile giungere ad una soluzione le variabili sono molte e come acennato da Fabrizio avere un mdb in una share non è una scelta felice...

    Giusto per approfondire la cosa, ad influenzare le performance  sono sicuramente  la versione del protocollo smb e l'opportunistic lock ( ho semplificato, diamo per scontato che hw e rete siano comparabili), purtroppo nella maggior parte dei casi (oserei dire nella totalità, vedi dente avvelenato di Ale) chi fa sviluppo, non sa nulla di ciò, perchè analisi e progettazione non vengono fatte... si conosce access, si usa access, poi fase di sviluppo, un mdb in locale monoutente, fine, il programma ha successo (ossia funziona), i clienti lo vogliono su piu' pc, allora lo si sposta in rete e con qualche raffazzonamento  lo trasforma in multiutente, con accessi multipli al singolo file... iniziano (ogni tanto) a verificarsi problemi, mai capiti, mai risolti!!

    Prova a vedere che versione di SMB hai, con questo comando powershell get-SMBconnection

    Si porebbe disabilitare oplock, scendere di versione smb (che sconsiglio, potrebbe generare altri problemi )

    Qui un po' info:

    https://blogs.technet.microsoft.com/netmon/2009/09/22/smb-opportunistic-locking-behavior/

    https://support.microsoft.com/en-us/kb/296264

    https://support.microsoft.com/en-us/kb/822219

    Anche altri db in rete hanno problemi:https://www.enercalc.com/pdf/ENERCALC_Network_File_Performance_Issues.pdf


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    venerdì 23 settembre 2016 20:58
    Moderatore
  • Grazie ad entrambi delle risposte, faremo al più presto queste verifiche.

    Ad Alessandro Vannini vorrei confermare che è chiarissimo il messaggio, soltanto ci troviamo in un caso molto particolare in cui un solo debug su Win10 non basta, visto che una parte di Win10 non manifesta problemi (quelli aggiornati da Win7) ed il programmatore ha eseguito i test proprio su uno di questi, la sorpresa si è manifestata solo da quando il cliente ha adottato pc nuovi nati come installazione Windows 10. A quanto pare serve più di un debug e scommetterei che poche software house avessero previsto che le nuove installazioni potessero comportarsi diversamente dai Windows aggiornati.
    Evidentemente si dovrà fare il debug della query incriminata anche su questa casistica comportandosi come se fosse un sistema operativo diverso.

    mercoledì 28 settembre 2016 07:13
  • Potrebbe dipendere anche dall'immagine OEM del produttore del computer se non sono stati riformattati dopo l'acquisto. Se non è stato ancora fatto, direi di provare con un'installazione pulita dell'ultima release stabile di Windows 10.

    mercoledì 28 settembre 2016 07:47
    Moderatore
  • Potrebbe dipendere anche dall'immagine OEM del produttore del computer se non sono stati riformattati dopo l'acquisto. Se non è stato ancora fatto, direi di provare con un'installazione pulita dell'ultima release stabile di Windows 10.

    Sono tutti pc che ho assemblato personalmente, con installato S.O. Windows Professional OEM su DVD, il problema è proprio sugli ultimi, macchine con appena 2 mesi di vita e nate con un'installazione pulita di Win 10 più relativi aggiornamenti, quindi non so se valga la pena reinstallare. Paradossalmente sono invece le installazioni più vecchie a non avere problemi, me ne vedo bene di toccarle, ma prima o poi può essere che vada fatto, quindi meglio capire per tempo cosa hanno di speciale.

    Manca però ancora su tutti l'aggiornamento "anniversario" uscito in questi giorni, non so se possa introdurre novità anche sotto questo aspetto.

    mercoledì 28 settembre 2016 08:03
  • Pilloso...scusami ma anche li...devo dissentire...ma come degli assemblati...in ambito professionale?? Ma come fai che ogni pezzo ha una sua strada e se hai delle incompatiblità nessuno te le risolve perchè non hai dietro un supporto di un brand...l'assemblato va bene a casa propria per giocare...ma non si danno in aziende in produzione dai...il problema del debug a questo punto passa in secondo piano...e se è un insieme di incompatiblità hardware + software driver sconosciuta? quando la trovi?

    A.

    mercoledì 28 settembre 2016 09:34
    Moderatore
  • Pilloso...scusami ma anche li...devo dissentire...ma come degli assemblati...in ambito professionale?? Ma come fai che ogni pezzo ha una sua strada e se hai delle incompatiblità nessuno te le risolve perchè non hai dietro un supporto di un brand...l'assemblato va bene a casa propria per giocare...ma non si danno in aziende in produzione dai...il problema del debug a questo punto passa in secondo piano...e se è un insieme di incompatiblità hardware + software driver sconosciuta? quando la trovi?

    A.

    Mi spiace tanto ma qui devo dissentire io, i problemi si hanno anche su macchine di marchi blasonati che contengono motherboard di dubbia produzione e mille utility preinstallate dalla casa, oltretutto spesso sprovviste dei dischi di ripristino. Non scherziamo per favore, se tutto si riduce al dare la colpa ai pc il thread prende una piega decisamente poco professionale.
    mercoledì 28 settembre 2016 10:24
  • Non scherziamo per favore, se tutto si riduce al dare la colpa ai pc il thread prende una piega decisamente poco professionale.

    mi fermo qui. Mi spiace. Se uno mi parla di un brand dove hai una piastra intel, un processore intel, un supporto h24 e 3 anni di garanzia, di fascia PRO (dove non c'è nulla di nulla di preinstallato) e lo paragona ad un assemblato non so più cosa ribattere.

    Tutti i problemi iniziali di un'incompatibilità sw derivano da un'incompatibilità hardware + software che deve essere scartata a priori e con un'assemblato non sei in grado di farlo, questa è la realtà.

    Se poi non vuoi sentirtelo dire perchè lo ritieni poco professionale siamo agli antipodi perchè nella mia professionalità l'assemblato non entra in nessuna delle mie aziende, nemmeno se costa 300€ in più di una macchina brandizzata e sappiamo bene che chi compra assemblati NON vuole spendere 300€ in più. Dovevi comunque comunicarci fin da subito il discordo dell'assemblato, vedrai che anche i colleghi intervenuti avranno i miei stessi dubbi. Buon proseguimento.

    A. 

    mercoledì 28 settembre 2016 12:56
    Moderatore
  • Mi spiace tanto ma qui devo dissentire io, i problemi si hanno anche su macchine di marchi blasonati che contengono motherboard di dubbia produzione e mille utility preinstallate dalla casa, oltretutto spesso sprovviste dei dischi di ripristino.

    Diciamo che ci sono computer preassemblati di fascia "consumer" e quelli di fascia professionale. Nel primo caso, il produttore garantisce solo l'hardware (scelta dei componenti, ecc..), ma non l'immagine di sistema che non è quindi concepita per ambiti aziendali. Nel secondo caso (più raro) l'OEM certifica il prodotto per un uso professionale, quindi ha anche il supporto tecnico qualificato per identificare problemi a livello aziendale.

    Nel caso degli assemblati hai una garanzia solo sul funzionamento del singolo componente, ma non dell'intero sistema, quindi potrebbero anche esserci problemi di compatibilità tra i singoli componenti.

    Ora non so se nel tuo caso possa dipendere effettivamente da una scelta dei componenti o da altro, intanto però anche eseguire l'upgrade alla versione 1607 di Windows 10 potrebbe aiutare.


    mercoledì 28 settembre 2016 13:29
    Moderatore
  • mi fermo qui. Mi spiace. Se uno mi parla di un brand dove hai una piastra intel, un processore intel, un supporto h24 e 3 anni di garanzia, di fascia PRO (dove non c'è nulla di nulla di preinstallato) e lo paragona ad un assemblato non so più cosa ribattere.[...]
    Dovevi comunque comunicarci fin da subito il discordo dell'assemblato, vedrai che anche i colleghi intervenuti avranno i miei stessi dubbi. Buon proseguimento.

    A. 

    Mi pare un po' eccessivo arrivare ad affermare che un database non può girare su un pc assemblato e spostare le responsabilità sulle macchine, e comunque parliamo di assemblato di qualità, con tutto Intel e con garanzia, e con intervento di assistenza risolutivo anche entro la giornata lavorativa, se proprio vogliamo puntualizzare, perchè i miei clienti lavorano senza interruzioni e non possono attendere i tempi di un call center.

    E' Microsoft a commercializzare sistemi OEM Professional per pc assemblati, se ritiene che un assemblato non possa essere affidabile in ambito professional, dovrebbe per serietà ritirarli dal commercio.
    Comunque posso fare una prova dal cliente con un HP Probook così quando appuriamo che anche un pc marcato di fascia professionale presenta lo stesso problema, forse potremo superare questa diatriba e tornare al problema reale.

    mercoledì 28 settembre 2016 13:44
  •  potremo superare questa diatriba e tornare al problema reale.

    che resta sempre: chi produce il software deve fare il debug sulle nuove versioni del sistema operativo in commercio oppure scartarle dalla compatibilità così che il cliente (TU) non perda giorni e giorni a cercare soluzioni che dovrebbe cercare la software house, non noi, non il cliente, non Microsoft stessa.

    Esiste sempre un canale per le software house che si chiama Microsoft Certified, è sempre esistito. Costa ma hai un sw certificato Windows con tanto di patacchino, allora li ti cercano le soluzioni, ma tranquillo, in quel caso se il sw non gira su una piattaforma la casa madre sa già il perchè.

    Ciao.

    A.


    mercoledì 28 settembre 2016 13:57
    Moderatore