Gli utenti spesso lamentano che "1C 8.3 è lento": i moduli dei documenti si aprono lentamente, i documenti impiegano molto tempo per essere elaborati, il programma si avvia, i report impiegano molto tempo per essere generati e così via.

Inoltre, tali "problemi" possono verificarsi in diversi programmi:

Le ragioni potrebbero essere diverse. Non si tratta di documenti ripristinati, un computer o server debole, il server 1C è configurato in modo errato.

In questo articolo voglio esaminare uno dei motivi più semplici e comuni lavoro lento programmi – . Questa istruzione sarà rilevante per gli utenti di database di file per 1-2 utenti, dove non esiste competizione per le risorse.

Se sei interessato a un'ottimizzazione più seria delle opzioni client-server per il funzionamento del sistema, visita la sezione del sito.

Dove sono le attività pianificate in 1C 8.3?

Prima che avessi il tempo di caricare il programma, 1C ne ha eseguiti molti lavori in sottofondo. Puoi visualizzarli accedendo al menu "Amministrazione", quindi "Supporto e manutenzione":

Ottieni 267 lezioni video su 1C gratuitamente:

Ecco come appare la finestra con le attività completate:

E così elenco completo tutti compiti di routine, che vengono lanciati:

Tra questi compiti ci sono "", caricare vari classificatori, verificare la pertinenza della versione del programma e così via. Ad esempio, non mi servono quasi tutte queste attività. Non tengo registri sulle valute, controllo personalmente le versioni e carico i classificatori secondo necessità.

Di conseguenza, è nel mio (e nella maggior parte dei casi nel tuo) interesse disabilitare le attività non necessarie.

Disabilitare le attività pianificate e in background in 1C 8.3

1) guarda la quantità di memoria allocata da rphost sul server 1C. Se disponi di una versione x32 del server, il processo può utilizzare un massimo di 1,75 GB di RAM
Se la memoria non è sufficiente, il server non può accettare nuove connessioni o si blocca quando la sessione corrente richiede memoria aggiuntiva
www.viva64.com/ru/k/0036
2) Guarda le impostazioni "Impostazioni server funzionante"; le impostazioni potrebbero essere errate. Ho avuto questo problema e il server continuava a bloccarsi. Le mie impostazioni sono allegate. Al server vengono assegnati 11 GB.
3) Potrebbero esserci problemi nella configurazione di Postgressql.

Fornisci le caratteristiche del tuo server, le dimensioni del database, le configurazioni Postgressql. È difficile dirlo senza informazioni.

La mia configurazione PostgreSQL: https://drive.google.com/file/d/0B2qGCc-vzEVDMERVW...
Questa configurazione è selezionata per la quantità di RAM disponibile.
PostgreSQL installato su Linux, 3 GB di RAM, 3 core CPU.
Server 1C8: 11 GB RAM, 5 core CPU
4 database da circa 1 GB ciascuno (caricati su dt)

Fornisci tutte le caratteristiche del tuo server: server e database 1C8, fisico o virtuale, sistema operativo, quantità di RAM su ciascun server, che tipo di CPU, quanta RAM occupano i processi rphost, quanti sono? Stai utilizzando un array RAID?

In precedenza, utilizzavo PostgreSQL da solo, ma durante il processo ho riscontrato alcuni problemi durante l'esecuzione di un database su PostgreSQL e recentemente sono passato a MS SQL.

Il tuo server non è male per questi database. Per utilizzare PostgreSQL è necessario avere un'ottima conoscenza della sua configurazione. Quando i database sono piccoli, molti errori di configurazione vengono perdonati. Quando abbiamo appena iniziato a implementare 1C + PostgreSQL, abbiamo avuto anche problemi molto frequenti con il funzionamento del database (si verificavano frequenti blocchi, funzionava lentamente). PostgreSQL è meglio utilizzato su Linux, non su Windows. Io stesso non sono uno specialista di database; per configurare il server del database abbiamo assunto uno specialista di 1Sbit e lui lo ha configurato per noi e da allora non ci sono stati problemi di funzionamento.

Consiglio:
Hai database di grandi dimensioni, non lesinare, assumi uno specialista di database che possa configurarlo per te. Una persona non può essere esperta in tutto.

1) quanto tempo fa hai controllato il database stesso e lo hai reindicizzato? VUOTO e REINDEX
2) quanto tempo fa hai testato e corretto il database utilizzando gli strumenti 1C?
3) il file di registro del database è posizionato su un HDD separato?
4) l'HDD è molto caricato?

Considera il passaggio a MS SQL, spesso non richiede “praticamente” alcuna configurazione ed è più facile da usare; A differenza di PostgreSQL, MS SQL è pronto per funzionare immediatamente, ma PostgreSQL deve essere configurato.

Se avete domande scrivete, magari posso aiutarvi con qualcosa su Skype: tisartisar

Assumi uno specialista nella configurazione di database

Perché siamo passati a MS SQL:
Utilizziamo la configurazione UT e alla chiusura del mese a volte si verificavano errori che non potevano essere risolti. Se hai trasferito il database in modalità file e hai iniziato a chiudere il mese, tutto si è chiuso normalmente, è stato caricato lo stesso database Server PostgreSQL Si sono verificati errori durante il calcolo del costo. All'epoca eravamo in ritardo di sei mesi negli ultimi mesi a causa di errori fluttuanti. Abbiamo creato un database di prova su MS SQL e il mese che non poteva essere chiuso su PostgreSQL su MS Sql è stato chiuso. Inoltre, l'arrotondamento dei prezzi nel listino prezzi non funziona correttamente su PostgreSQL. Infatti, l'esecuzione di 1C su PostgreSQL è supportata, ma è comunque consigliabile utilizzare MS SQL.
Per questo motivo si è deciso di passare a MS SQL perché... la stabilità dell'operazione 1C è più costosa.

Sono felice di poterti aiutare, contattami se hai domande o problemi.

1) quanta memoria è allocata al server MS SQL? questo è configurato nel server MS SQL stesso.
2) Testare regolarmente il database utilizzando 1C
3) articolo su come impostare backup e manutenzione. Questo è importante e deve essere fatto regolarmente. Lo faccio ogni giorno. Dai un'occhiata a tutte e 3 le parti della guida.

IN ultimamente Utenti e amministratori cominciano sempre più a lamentarsi del fatto che le nuove configurazioni 1C sviluppate sulla base di un'applicazione gestita sono lente, in alcuni casi inaccettabilmente lente. È chiaro che le nuove configurazioni contengono nuove funzioni e capacità e quindi richiedono più risorse, ma la maggior parte degli utenti non capisce cosa influenza principalmente il funzionamento di 1C in modalità file. Proviamo a correggere questa lacuna.

Nel nostro abbiamo già accennato all’impatto della produttività sottosistema del disco alla velocità di 1C, tuttavia questo studio riguardava l'uso locale dell'applicazione su un PC separato o server terminale. Allo stesso tempo, la maggior parte delle piccole implementazioni implicano il lavoro con un database di file su una rete, dove uno dei PC dell’utente viene utilizzato come server, o un file server dedicato basato su un computer normale, molto spesso anche economico.

Lo ha dimostrato un piccolo studio sulle risorse 1C in lingua russa questa domanda lo evita diligentemente; se sorgono problemi, di solito si consiglia di passare alla modalità client-server o terminale. Inoltre è ormai quasi generalmente accettato che le configurazioni su un'applicazione gestita funzionino molto più lentamente del solito. Di norma, gli argomenti sono “di ferro”: “La contabilità 2.0 è appena volata e la “troika” si è appena mossa. Naturalmente, c'è del vero in queste parole, quindi proviamo a capirlo.

Consumo di risorse, a prima vista

Prima di iniziare questo studio, ci siamo prefissati due obiettivi: scoprire se le configurazioni basate su applicazioni gestite sono effettivamente più lente delle configurazioni convenzionali e quali risorse specifiche hanno l'impatto principale sulle prestazioni.

Per i test, abbiamo preso due macchine virtuali che eseguono rispettivamente Windows Server 2012 R2 e Windows 8.1, assegnandole con 2 core dell'host Core i5-4670 e 2 GB RAM, che corrisponde approssimativamente alla macchina da ufficio media. Il server è stato posizionato su un array RAID 0 di due, mentre il client è stato posizionato su un array simile di dischi per uso generale.

Come basi sperimentali, abbiamo selezionato diverse configurazioni di Accounting 2.0, release 2.0.64.12 , che è stato poi aggiornato a 3.0.38.52 , tutte le configurazioni sono state lanciate sulla piattaforma 8.3.5.1443 .

La prima cosa che attira l’attenzione è l’aumento delle dimensioni della base informativa della Troika, che è cresciuta in modo significativo, così come un appetito molto maggiore per la RAM:

Siamo pronti a sentire la solita: “perché hanno aggiunto anche questo a questi tre?”, ma non affrettiamoci. A differenza degli utenti delle versioni client-server, che richiedono un amministratore più o meno qualificato, gli utenti delle versioni file raramente pensano alla manutenzione dei database. Inoltre, i dipendenti di aziende specializzate che forniscono assistenza (leggi aggiornamento) a questi database raramente ci pensano.

Nel frattempo, la base informativa 1C è un DBMS a tutti gli effetti del proprio formato, che richiede anche manutenzione, e per questo esiste anche uno strumento chiamato Testare e correggere la base di informazioni. Forse il nome ha giocato uno scherzo crudele, il che in qualche modo implica che si tratta di uno strumento per la risoluzione dei problemi, ma anche le basse prestazioni sono un problema e la ristrutturazione e la reindicizzazione, insieme alla compressione delle tabelle, sono strumenti ben noti per l'ottimizzazione dei database. Controlliamo?

Dopo aver applicato le azioni selezionate, il database ha “perso peso” nettamente, diventando ancora più piccolo dei “due”, che nessuno aveva mai ottimizzato, e anche il consumo di RAM è leggermente diminuito.

Successivamente, dopo aver caricato nuovi classificatori e directory, creato indici, ecc. la dimensione della base aumenterà; in generale, le “tre” basi sono più grandi delle “due” basi. Tuttavia, questo non è più importante, se la seconda versione si accontentava di 150-200 MB di RAM, la nuova edizione richiederà mezzo gigabyte e questo valore dovrebbe essere preso in considerazione quando si pianificano le risorse necessarie per lavorare con il programma.

Netto

La larghezza di banda della rete è uno dei parametri più importanti per le applicazioni di rete, in particolare come 1C in modalità file, che sposta quantità significative di dati attraverso la rete. La maggior parte delle reti di piccole imprese sono costruite sulla base di apparecchiature economiche da 100 Mbit/s, quindi abbiamo iniziato i test confrontando gli indicatori di prestazione 1C nelle reti da 100 Mbit/s e 1 Gbit/s.

Cosa succede all'avvio banca dati dei file 1C sulla rete? Il client ne scarica una quantità sufficiente nelle cartelle temporanee gran numero informazioni, soprattutto se questo è il primo avvio “a freddo”. A 100 Mbit/s si prevede di raggiungere la larghezza del canale e il download può richiedere molto tempo, nel nostro caso circa 40 secondi (il costo per dividere il grafico è di 4 secondi).

Il secondo avvio è più veloce, poiché alcuni dati vengono archiviati nella cache e rimangono lì fino al riavvio. Il passaggio a una rete Gigabit può accelerare notevolmente il caricamento del programma, sia "a freddo" che "a caldo", e il rapporto tra i valori viene rispettato. Pertanto, abbiamo deciso di esprimere il risultato in valori relativi, prendendo il massimo grande valore ogni misurazione:

Come puoi vedere dai grafici, Accounting 2.0 si carica a qualsiasi velocità di rete due volte più velocemente, il passaggio da 100 Mbit/s a 1 Gbit/s consente di accelerare di quattro volte il tempo di download. In questa modalità non vi è alcuna differenza tra i database "troika" ottimizzati e non ottimizzati.

Abbiamo anche verificato l'influenza della velocità della rete sul funzionamento in modalità pesanti, ad esempio durante i trasferimenti di gruppo. Il risultato è espresso anche in valori relativi:

Qui è più interessante, la base ottimizzata dei “tre” in una rete a 100 Mbit/s funziona alla stessa velocità dei “due”, e quella non ottimizzata mostra risultati due volte peggiori. Su Gigabit, i rapporti rimangono gli stessi, anche il “tre” non ottimizzato è lento la metà del “due” e quello ottimizzato è indietro di un terzo. Inoltre, il passaggio a 1 Gbit/s consente di ridurre i tempi di esecuzione di tre volte per l'edizione 2.0 e della metà per l'edizione 3.0.

Per valutare l'impatto della velocità della rete sul lavoro quotidiano, abbiamo utilizzato Misurazione delle prestazioni, eseguendo una sequenza di azioni predeterminate in ciascun database.

In realtà, per le attività quotidiane, il throughput della rete non è un collo di bottiglia, un "tre" non ottimizzato è solo il 20% più lento di un "due" e dopo l'ottimizzazione risulta essere più o meno lo stesso più veloce: i vantaggi di lavorare in modalità thin client sono evidenti. Il passaggio a 1 Gbit/s non offre alcun vantaggio alla base ottimizzata, mentre quella non ottimizzata e le due iniziano a funzionare più velocemente, mostrando una piccola differenza tra loro.

Dai test effettuati risulta chiaro che la rete non rappresenta un collo di bottiglia per le nuove configurazioni e l'applicazione gestita funziona ancora più velocemente del solito. Puoi anche consigliare di passare a 1 Gbit/s se i compiti pesanti e la velocità di caricamento del database sono fondamentali per te; in altri casi, le nuove configurazioni ti consentono di lavorare in modo efficace anche su reti lente a 100 Mbit/s;

Allora perché 1C è lento? Lo esamineremo ulteriormente.

Sottosistema disco del server e SSD

Nell'articolo precedente abbiamo ottenuto un aumento delle prestazioni 1C posizionando i database su un SSD. Forse le prestazioni del sottosistema disco del server sono insufficienti? Abbiamo misurato le prestazioni di un disk server durante un'esecuzione di gruppo in due database contemporaneamente e abbiamo ottenuto un risultato piuttosto ottimistico.

Nonostante il numero relativamente elevato di operazioni di input/output al secondo (IOPS) - 913, la lunghezza della coda non ha superato 1,84, il che è un ottimo risultato per un array a due dischi. Sulla base di ciò, possiamo supporre che un mirror realizzato con dischi ordinari sarà sufficiente per il normale funzionamento di 8-10 client di rete in modalità pesante.

Quindi è necessario un SSD su un server? Il modo migliore per rispondere a questa domanda sarà attraverso i test, che abbiamo condotto utilizzando un metodo simile, connessione di rete ovunque 1 Gbit/s il risultato è espresso anche in valori relativi.

Cominciamo con la velocità di caricamento del database.

Ad alcuni potrebbe sembrare sorprendente, ma l'SSD sul server non influisce sulla velocità di caricamento del database. Il principale fattore limitante qui, come ha dimostrato il test precedente, è il throughput della rete e le prestazioni del client.

Passiamo al rifacimento:

Abbiamo già notato sopra che le prestazioni del disco sono abbastanza sufficienti anche per lavorare in modalità pesante, quindi anche la velocità dell'SSD non viene influenzata, ad eccezione della base non ottimizzata, che sull'SSD ha raggiunto quella ottimizzata. In realtà, ciò conferma ancora una volta che le operazioni di ottimizzazione organizzano le informazioni nel database, riducendo il numero di operazioni di I/O casuali e aumentando la velocità di accesso ad esso.

Nelle attività quotidiane il quadro è simile:

Solo il database non ottimizzato beneficia dell'SSD. Ovviamente puoi acquistare un SSD, ma sarebbe molto meglio pensare alla manutenzione tempestiva del database. Inoltre, non dimenticare di deframmentare la sezione con le infobase sul server.

Sottosistema del disco client e SSD

Abbiamo analizzato l'influenza dell'SSD sulla velocità di funzionamento dell'1C installato localmente, molto di quanto detto vale anche per il funzionamento in modalità di rete. In effetti, 1C utilizza abbastanza attivamente le risorse del disco, anche per attività in background e di routine. Nella figura seguente puoi vedere come Accounting 3.0 accede abbastanza attivamente al disco per circa 40 secondi dopo il caricamento.

Ma allo stesso tempo dovresti essere consapevole che per una workstation in cui viene svolto un lavoro attivo con uno o due database di informazioni, le risorse prestazionali di un normale HDD prodotto in serie sono abbastanza sufficienti. L’acquisto di un SSD può velocizzare alcuni processi, ma non noterai una radicale accelerazione nel lavoro quotidiano, poiché, ad esempio, il download sarà limitato dalla larghezza di banda della rete.

Lento disco rigido può rallentare alcune operazioni, ma da solo non può rallentare il programma.

RAM

Nonostante il fatto che la RAM sia ora oscenamente economica, molte workstation continuano a funzionare con la quantità di memoria installata al momento dell'acquisto. È qui che si profilano i primi problemi. Già in base al fatto che la "troika" media richiede circa 500 MB di memoria, possiamo supporre che la quantità totale di RAM di 1 GB non sarà sufficiente per lavorare con il programma.

Abbiamo ridotto la memoria di sistema a 1 GB e lanciato due database di informazioni.

A prima vista non va tutto così male, il programma ha frenato i suoi appetiti e si è adattato bene alla memoria disponibile, ma non dimentichiamo che la necessità di dati operativi non è cambiata, quindi dove sono finiti? Ripristina disco, cache, scambio, ecc., l'essenza di questa operazione è che non è necessaria al momento i dati vengono inviati dalla RAM veloce, la cui quantità non è sufficiente, alla memoria del disco lenta.

A cosa porterà questo? Vediamo come vengono utilizzate le risorse di sistema nelle operazioni pesanti, ad esempio, lanciamo un ritrasferimento di gruppo in due database contemporaneamente. Prima su un sistema con 2 GB di RAM:

Come possiamo vedere, il sistema utilizza attivamente la rete per ricevere i dati e il processore per elaborarli; l'attività del disco durante l'elaborazione aumenta occasionalmente, ma non è un fattore limitante;

Ora riduciamo la memoria a 1 GB:

La situazione sta cambiando radicalmente, il carico principale ora ricade sul disco rigido, il processore e la rete sono inattivi, in attesa che il sistema legga i dati necessari dal disco in memoria e invii lì i dati non necessari.

Allo stesso tempo, anche il lavoro soggettivo con due database aperti su un sistema con 1 GB di memoria si è rivelato estremamente scomodo, directory e riviste aperte con un ritardo significativo e accesso attivo al disco; Ad esempio, l'apertura del giornale delle vendite di beni e servizi ha richiesto circa 20 secondi ed è stata accompagnata per tutto questo tempo da un'elevata attività del disco (evidenziata con una linea rossa).

Per valutare oggettivamente l'impatto della RAM sulle prestazioni delle configurazioni basate su un'applicazione gestita, abbiamo effettuato tre misurazioni: la velocità di caricamento del primo database, la velocità di caricamento del secondo database e la riesecuzione del gruppo in uno dei database . Entrambi i database sono completamente identici e sono stati creati copiando il database ottimizzato. Il risultato è espresso in unità relative.

Il risultato parla da solo: se il tempo di caricamento aumenta di circa un terzo, il che è ancora abbastanza tollerabile, allora il tempo per eseguire le operazioni nel database aumenta di tre volte, non c'è bisogno di parlare di lavoro confortevole in tali condizioni. A proposito, questo è il caso in cui l'acquisto di un SSD può migliorare la situazione, ma è molto più semplice (ed economico) affrontare la causa, non le conseguenze, e acquistare semplicemente la giusta quantità di RAM.

La mancanza di RAM è il motivo principale per cui lavorare con le nuove configurazioni 1C risulta scomodo. Le configurazioni con 2 GB di memoria a bordo sono da considerarsi minimamente idonee. Allo stesso tempo, tieni presente che nel nostro caso si sono create le condizioni di una “serra”: un sistema pulito, solo 1C e il task manager erano in esecuzione. IN vita reale su un computer di lavoro, di norma, è aperto un browser, una suite per ufficio, è in esecuzione un antivirus, ecc. Ecc., quindi procedi dalla necessità di 500 MB per database più una certa riserva, in modo che durante le operazioni pesanti lo fai non incontrare una mancanza di memoria e un forte calo della produttività.

processore

Senza esagerare, il processore centrale può essere definito il cuore del computer, poiché è alla fine che elabora tutti i calcoli. Per valutarne il ruolo, abbiamo condotto un'altra serie di test, gli stessi della RAM, riducendo il numero di core a disposizione della macchina virtuale da due a uno, e il test è stato eseguito due volte con quantità di memoria di 1 GB e 2 GB.

Il risultato si è rivelato piuttosto interessante e inaspettato: un processore più potente ha assunto il carico in modo abbastanza efficace quando mancavano le risorse, il resto del tempo senza fornire vantaggi tangibili. 1C Enterprise (in modalità file) difficilmente può essere definita un'applicazione che utilizza attivamente le risorse del processore; è piuttosto poco impegnativa. E in condizioni difficili, il processore è gravato non tanto dal calcolo dei dati dell'applicazione stessa, ma dal mantenimento dei costi generali: operazioni di input/output aggiuntive, ecc.

Conclusioni

Quindi, perché 1C è lento? Prima di tutto, si tratta di una mancanza di RAM; il carico principale in questo caso ricade sul disco rigido e sul processore. E se non brillano in termini di prestazioni, come di solito accade nelle configurazioni da ufficio, otteniamo la situazione descritta all'inizio dell'articolo: i "due" hanno funzionato bene, ma i "tre" sono incredibilmente lenti.

Al secondo posto ci sono le prestazioni della rete; un canale lento a 100 Mbit/s può diventare un vero collo di bottiglia, ma allo stesso tempo la modalità thin client è in grado di mantenere un livello di funzionamento abbastanza confortevole anche su canali lenti.

Allora dovresti prestare attenzione all'unità disco; acquistare un SSD difficilmente sarà un buon investimento, ma sostituire l'unità con una più moderna sarebbe una buona idea. La differenza tra generazioni dischi rigidi può essere valutato da al materiale seguente: .

E infine il processore. Un modello più veloce non sarà certamente superfluo, ma ha molto senso Non c'è modo di aumentarne le prestazioni, a meno che questo PC non venga utilizzato per operazioni pesanti: elaborazioni di gruppo, report pesanti, chiusura del mese, ecc.

Speriamo questo materiale ti aiuterà a comprendere rapidamente la domanda "perché 1C è lento" e a risolverla nel modo più efficace e senza costi aggiuntivi.

• Tag:

Abilita JavaScript per visualizzare il

L'impatto del blocco sulle prestazioni di 1C:Enterprise 8

Il team gilev si occupa da molti anni di problemi di prestazioni e ha risolto con successo, tra le altre cose, il problema dell'eliminazione delle attese su lock e deadlock.

Di seguito descriveremo la nostra esperienza nella risoluzione di questi problemi.

Rilevamento di problemi di blocco in 1C

I problemi di prestazioni in modalità multiplayer non sono necessariamente legati a codice o hardware difettosi. Innanzitutto dobbiamo rispondere alla domanda: quali problemi di prestazioni esistono e cosa li causa?

È impossibile tracciare manualmente le attività di centinaia di utenti; è necessario uno strumento che automatizzi la raccolta di tali informazioni.

Esistono molti strumenti, ma quasi tutti presentano uno svantaggio molto significativo: il prezzo.

Ma c'è una via d'uscita: scegliamo

Esamineremo il problema su MS SQL Server, quindi avremo bisogno dei seguenti servizi da questo set:

1. Monitoraggio e analisi delle richieste lunghe(leggi di più sulla costituzione qui) - necessario per valutare se ci sono operazioni a lungo termine per il sottod.

In realtà, il fatto della loro presenza ci permette di dire che ci sono problemi di prestazioni, e i problemi risiedono nelle righe del codice di configurazione 1C, che il servizio classificherà in base all'importanza. I problemi in cima all’elenco devono essere risolti per primi. Tali soluzioni alle linee problematiche porteranno l'effetto maggiore, ad es. sarà di grande beneficio e beneficio per gli utenti del sistema.

(leggi di più qui) ci permetterà di valutare se il tempo delle richieste lunghe (lunghe) è effettivamente causato dall'attesa dei lock oppure ci sono altri motivi (codice non ottimale, hardware sovraccarico, ecc.) Il servizio mostrerà il motivo dell'interruzione l'attesa da parte della richiesta, ovvero la risorsa che è stata bloccata e chi l'ha bloccata. Quelli. comprenderemo la presenza di problemi bloccanti e le loro cause.

3. Analisi dei blocchi reciproci nel server 1C e MS SQL(maggiori informazioni sulla configurazione qui) - ci consentiranno di valutare di più situazioni difficili con l'attesa delle risorse, quando diversi partecipanti sono già riusciti a “catturare” alcune risorse bloccandole e ora sono costretti ad aspettarsi a vicenda perché non possono rilasciare le risorse occupate finché non viene completata la cattura di altre risorse bloccate dai vicini.

In generale, una situazione così difficile non può essere risolta manualmente, è necessario un tale servizio.

4. Controllo del carico dell'attrezzatura(maggiori informazioni sulla configurazione qui) ci aiutano a rispondere alle domande: quanti utenti sono presenti nel sistema, hanno blocchi, quanti blocchi ci sono, l'hardware può far fronte al carico?

I servizi sono molto facili da configurare, ma anche se hai ancora domande, ce ne sono!

Utilizzando gli strumenti sopra elencati, disponiamo di informazioni oggettive sulle prestazioni del sistema. Ciò ci consente di valutare correttamente la situazione e proporre misure adeguate.

Infatti, riceviamo informazioni su tutti i problemi di prestazione e possiamo rispondere con precisione a domande come “quanti problemi ci sono nel sistema”, “dove si verificano esattamente”, “ciascun problema con quale frequenza esatta si verifica”, “quali problemi sono significativi e quali minori”. Quelli. vediamo tutti i prerequisiti che hanno costituito la causa del problema.

I servizi ti consentono di migliorare significativamente la tua comprensione delle condizioni in cui sorgono i problemi, senza costringerti ad approfondire manualmente cose come la struttura di archiviazione dei dati della base informativa a livello DBMS, il meccanismo di blocco, ecc.

Di conseguenza, otteniamo un quadro delle prestazioni che vengono misurate

— tempo di richiesta (ovviamente, classificando le richieste problematiche in base al peso (tempo di richiesta in base al numero di chiamate a tale richiesta);

— tempo di attesa per le serrature;

Per questo abbiamo lanciato il servizio Analisi delle aspettative sui blocchi

Nella tabella in alto, il servizio riporta l’elenco delle “vittime” del blocco, tenendo conto del peso complessivo della “gravità delle aspettative”.

Nella tabella inferiore, per ciascuna vittima vengono considerati uno o più partecipanti alla “lotta per una risorsa altamente competitiva”, dove nasceva l'attesa per il blocco.

Nella tabella inferiore, apri i dettagli di uno degli eventi di “timeout”. Come nella foto per esempio.

Evidenziando la riga con il “colpevole”, vedremo che il collo di bottiglia era la tabella _Reference64, e si è verificato un problema sull'indice cluster con l'area “sconosciuta”. Forse in futuro lo ribattezzeremo “tabella”, poiché in effetti questo comportamento è tipico per aumentare/allargare l'area di blocco.

La riga con la “vittima” mostra quale codice era ostaggio della situazione e non poteva bloccare tutto, solo la riga “per chiave” (l'area minima di blocco dei dati in questa tabella).

Questo problema può essere risolto “correttamente” e “facilmente”.

Di nel modo giustoè più difficile da fare: in realtà devi riscrivere il codice, riducendo al minimo la probabilità che si verifichino tali situazioni.

Uno dei fattori, per quanto strano possa sembrare, è una diminuzione della durata.

Puoi ridurre la durata della transazione:

1. riscrivere l'algoritmo

2. riscrivendo la query (una query più veloce riduce la probabilità di blocchi in transazioni complesse su tabelle, che a volte potrebbero anche non essere presenti nella query!)

2.1 aggiunta dell'indice di copertura mancante (a volte un indice non solo velocizza la query, ma riduce anche l'area di lettura dei dati, riducendo così la probabilità di blocco)

3. ridurre la quantità di dati trattati in una transazione (oltre alla velocità lineare ricordiamo anche la lock escalation)

4. aumentare le prestazioni delle apparecchiature all'interno di ciascun flusso

Richiedi l'ora di esecuzione

1) utenti diversi possono lavorare in parallelo con dati diversi
2) utenti diversi devono lavorare in modo rigorosamente sequenziale con gli stessi dati

È possibile però ottimizzare l’utilizzo delle serrature, riducendo così i tempi complessivi di attesa.

Come funziona il blocco (non è necessario leggere questo paragrafo)

Uno speciale modulo SQL Server, Lock Manager, gestisce i blocchi. I suoi compiti includono:

• creazione e installazione di serrature;
• sbloccaggio;
• escalation del blocco;
• determinare la compatibilità del blocco;
• eliminando le situazioni di stallo e molto altro ancora.

Quando un utente effettua una richiesta di aggiornamento o lettura di dati, il gestore delle transazioni DBMS passa il controllo al gestore dei blocchi DBMS per determinare se le risorse richieste sono state bloccate e, in tal caso, se il blocco richiesto è compatibile con quello corrente. Se i blocchi sono incompatibili, l'esecuzione della transazione corrente viene ritardata finché i dati non vengono sbloccati. Una volta che i dati sono disponibili, il gestore del lock acquisisce il lock richiesto e restituisce il controllo al gestore delle transazioni.

Il motivo principale che riduce le prestazioni è il blocco

Le attese di blocco rappresentano un grave problema di prestazioni in modalità multiplayer. E questo è comprensibile, perché aumentano i tempi di attesa per le operazioni, e quindi i tempi di risposta. È possibile affermare che l'attesa sui blocchi non sia corretta e sia un errore in un sistema multiutente? Questo non si può dire, poiché lo stesso meccanismo di blocco delle risorse garantisce l'integrità dei dati. Utilizzando il meccanismo di blocco, i dati simultanei vengono SCRIVTI CONSEQUENZIALMENTE.

Differenza tra serrature necessarie e non necessarie

Quando un utente segnala un errore in attesa di un blocco, dal suo punto di vista questo è sempre un errore, perché ad esempio interferisce con il suo lavoro: il tempo necessario per completare il suo lavoro aumenta.

L'esperienza suggerisce una regola semplice: se più della metà del tempo di esecuzione della richiesta è effettivamente in attesa di una risorsa bloccata, allora è necessario guardare: forse è possibile ottimizzare parte del blocco e ridurre il tempo di blocco della risorsa.

Qui, come per caso, introduco una definizione:

Aspettando sul blocco è una situazione che si verifica quando due utenti tentano di acquisire gli stessi dati contemporaneamente. In questo caso uno di questi utenti viene bloccato, ovvero deve attendere la fine della transazione del primo utente.

Una transazione è un insieme di calcoli e operazioni con dati (la maggior parte fulgido esempio— quando si redige un documento) eseguito nel suo insieme. Il mancato completamento di una qualsiasi delle operazioni della transazione comporta l'annullamento dell'intera transazione.

Pertanto, gli utenti nelle infobase multiutente possono spesso lamentarsi dell'impossibilità di lavorare a causa di questi blocchi, mentre il codice potrebbe effettivamente avere blocchi che non sono necessari in questo luogo (ridondanti).
E anche nel codice di configurazione, essi stessi potrebbero non essere presenti, puoi leggerli, ad esempio, qui http://kb.1c.ru/articleView.jsp?id=30 (l'articolo è un frammento del libro; di P.S. Belousov, A.V.Ostroverh “1C:Enterprise: da 8.0 a 8.1.”). Offro un modo semplificato per spiegare le differenze tra i blocchi semplice esempio COSÌ:

Nella tua configurazione in modalità 1C:Enterprise, crea due fatture identiche con la stessa composizione di merci. Assicurati però di indicare i diversi magazzini riceventi.
Nel codice di elaborazione della registrazione è necessario aggiungere una riga con un messaggio visualizzato sullo schermo (o altro codice che può ritardare l'esecuzione dell'elaborazione della registrazione di 21 secondi (il timeout del blocco avviene dopo 20 secondi se i parametri sono predefiniti)) .
Pubblica due documenti.
Se si verifica un timeout e logicamente la merce arriva in magazzini diversi, nell'applicazione sono presenti blocchi ridondanti. La logica aziendale (considera il buon senso) non dovrebbe esserci alcun blocco qui.
Se ora realizziamo magazzini identici in queste due fatture. Quindi il blocco creato a seguito di un tentativo di esecuzione simultanea porterà ad un blocco NECESSARIO e questo è BUONO!

Quelli. Mentre la fattura apporta modifiche ai saldi di magazzino, l'altra deve attendere.

Naturalmente, anche questo semplice esempio lascia molte domande. Ad esempio, cosa succede se i documenti provengono da un fornitore e il debito su di esso “si sposta”. E se a muoversi non sono solo i saldi di magazzino, ma diversi registri e documenti di diverso tipo.
Ma la domanda più importante è: CON QUALE LOGICA AZIENDALE NON DOVREBBERO ESISTERE BLOCCHI. Chi prescrive questa logica aziendale e dove nel contesto del blocco? Ma parliamo di tutto in ordine.

I blocchi eccessivi sono blocchi non necessari che non sono necessari dal punto di vista della garanzia dell'integrità dei dati e che allo stesso tempo riducono le prestazioni complessive del sistema, aumentando il tempo di inattività totale - attesa dei blocchi.
Il blocco necessario si verifica quando due utenti acquisiscono le stesse risorse (oggetti dati). Se gli utenti lavorano con risorse non sovrapposte, ma sono in attesa di un blocco, il blocco è considerato ridondante.

I criteri più comprensibili per il blocco della ridondanza sono:

1. Blocchi reciproci;

2. Il livello (area) di blocco è superiore al necessario (come caso speciale aumentando il livello di blocco, il cosiddetto. escalation);

3. Il tempo di blocco è più lungo del tempo di utilizzo “reale” dell'oggetto bloccante.

Avendo ricevuto informazioni sui raggruppamenti di problemi nel contesto dei metadati 1C:Enterprise, consiglio di prestare attenzione innanzitutto ai seguenti oggetti:

• Costanti
• Successione
• Registri contabili
• Registri di accumulo
• Registri di informazione
• Registri di calcolo

1) Fino a poco tempo fa esisteva la ben nota raccomandazione di non scrivere nulla nelle costanti. In casi estremi, fallo da sotto un utente, e poi ricorda che mentre l'utente “scrive” una costante, non solo questa, ma anche qualsiasi altra costante, gli altri utenti “aspetteranno”. Pertanto, è particolarmente pericoloso utilizzare costanti nell'elaborazione delle transazioni. I valori di tutte le costanti vengono memorizzati V una risorsa.

La figura mostra il posizionamento fisico delle costanti di configurazione SCP in una tabella di database MS SQL Server 2005.

Ciò significa che il blocco di una costante bloccherà tutte le costanti. Il DBMS impone un blocco su TUTTA la singola RIGA della tabella, ovvero per tutte le costanti.

Tuttavia, nelle ultime versioni della piattaforma, la memorizzazione delle costanti è stata modificata. Ora ogni costante è una tabella separata. Non lasciarti trasportare troppo, però, se crei migliaia di tabelle, puoi ottenere un blocco sulla base principale.

Attenzione, se la tua configurazione esiste da molto tempo, allora puoi modificare il formato di archiviazione “ristrutturandola” in Testare e Correggere il configuratore.

2) Rifiutarsi di utilizzare l'oggetto metadati Sequence. Almeno dai movimenti implementazione operativa, eseguire durante procedure non operative (aggiuntive). Guarda come è implementato in ultime versioni UPP.

3) Se il sistema effettua la registrazione online dei movimenti nel registro contabile in modalità multiutente, allora si consiglia:

• abilitare la modalità di separazione dei totali per questo registro;
• Non utilizzare il controllo del bilanciamento del registro durante il lavoro operativo.

4) Nel registro di accumulo, nei casi in cui non sia necessario ottenere dati “operativi”, è possibile abilitare la divisione dei totali, che aumenterà il parallelismo della registrazione dei dati e velocizzerà il lavoro in generale. Monitorare attentamente le misurazioni in modo che i “residui” possano essere ottenuti con il massimo dettaglio nelle misurazioni.

5) Puoi eliminare alcuni dei blocchi ridondanti creati dalla piattaforma solo tramite . Nella modalità operativa automatica delle configurazioni, la piattaforma “si fa carico” delle risorse bloccanti. Prezzo senza preoccupazioni modalità automatica— sono possibili blocchi ai limiti degli intervalli di indici, blocchi di tabelle vuote e escalation dei blocchi.

Questi blocchi scompaiono completamente dai dati della transazione. Cioè, questo interblocco non sarà possibile quando si opera in modalità controllata.

Ho già detto più volte “serrature gestite” e “modalità gestita”. Devi capire che esistono due tipi di serrature:
I blocchi DBMS vengono installati automaticamente a livello DBMS durante l'esecuzione delle query.
1C: I blocchi Enterprise vengono installati automaticamente durante la scrittura (modifica) dei dati e sempre manualmente durante la lettura dei dati.

Un lettore meticoloso dirà che 1C si divide anche in serrature oggetto e non oggetto, ma ora non toccheremo questo approccio.

Ma noto che impone più requisiti alle qualifiche e all'esperienza di uno specialista 1C.

6) Gli indici mancanti (soprattutto nelle query complesse) sono generalmente il fattore principale nel verificarsi di un livello di blocco più elevato del necessario. Quelli. paradosso, da un lato ho detto che prima di ottimizzare la query ho detto che bisogna prima guardare le serrature, ma ora dico che per ottimizzare le serrature bisogna ottimizzare la query. Ho una scusa, il passaggio dalla configurazione ai blocchi gestiti riduce i blocchi non necessari anche in una query non ottimale. Ciò si verifica a causa di una diminuzione del livello di isolamento della transazione, che a sua volta fornisce al gestore dei blocchi DBMS meno motivi per imporre un blocco eccessivo.

I motivi principali del blocco eccessivo (per riassumere quanto sopra)

— errori di progettazione
(il grado di parallelismo è determinato da “quanto finemente vengono tritati i dati”: è possibile lavorare in parallelo con due righe della tabella, lavorare con una riga avverrà solo in sequenza)
(errori nell'utilizzo dei metadati: registrazione di costanti, sequenze, contabilità operativa sui registri contabili)
— bloccaggio eccessivo a causa del guasto della modalità automatica (combinazione piattaforma-DBMS).
- prestazioni delle query non ottimali
(ad esempio, durante la scansione di una tabella, l'intera tabella è bloccata - area ridondante
e il tempo di blocco aumenta - tempo eccessivo, un ulteriore numero di blocchi aumenta la probabilità di un'escalation di blocchi)

Come puoi vedere, il compito di ottimizzare le serrature è “multiforme”. È necessario essere il più chiari possibile riguardo al “contesto” che ha causato il problema. Su quali risorse, quale codice. Quanto questo blocco è realmente necessario o è ridondante?

Un bambino e un adulto hanno mal di gola. Quando il medico pone la domanda: "Cosa c'è che non va?", il bambino guarderà il medico e urlerà (credetemi, lo so), mentre l'adulto gli indicherà i sintomi della malattia. Queste apparenti differenze indirizzano il medico verso metodi diversi per identificare il problema.
Con un bambino, il medico deve esibirsi molti test, raccogli dati, combinali, esegui analisi e solo dopo formula raccomandazioni. Mentre con un adulto farà diverse domande e, poiché il numero di dati iniziali è piccolo, il tempo per l'analisi e la determinazione del problema sarà notevolmente inferiore. Di conseguenza, le raccomandazioni verranno emanate molto prima.

Utilizza i nostri servizi e avrai più opportunità di analizzare gratuitamente il problema e trovare una soluzione!

Il reclamo degli utenti "1C si blocca", ben noto agli specialisti IT, ha molte ragioni. Per effettuare una "diagnosi" corretta, identificando e analizzando un problema, è necessario riprodurlo, poiché un problema che non può essere riprodotto è, di regola, quasi impossibile da risolvere. Avendo compreso i sintomi del congelamento 1C, faremo il primo passo verso un sistema che funzioni in modo efficiente.

Avvio del sistema molto lungo

Un lungo avvio di una configurazione pesante sotto un utente per la prima volta dopo aver aggiunto la sicurezza delle informazioni all'elenco dei database sul computer è un fenomeno normale. Durante il primo avvio, la configurazione viene memorizzata nella cache. La seconda e le successive esecuzioni dovrebbero essere più veloci.

L'avvio del sistema che richiede molto tempo può indicare problemi con l'implementazione architetturale della configurazione. La maggior parte della configurazione viene letta dalla piattaforma solo la prima volta che si accede all'oggetto metadati desiderato. Un avvio lungo indica la probabilità di utilizzo gran numero oggetti di metadati (molte chiamate a vari moduli comuni, elaborazione, ecc.).

Va tenuto presente che la prima volta che si accede al testo di qualsiasi modulo, questo viene compilato. Anche questo processo richiede tempo, il che è particolarmente evidente se i moduli sono molti. Pertanto, il problema dell'avvio lento viene risolto modificando (ottimizzando) la configurazione, il cui scopo è disabilitare l'esecuzione di tutti gli algoritmi opzionali che vengono eseguiti all'avvio del sistema.

È possibile che la configurazione stia tentando di leggere dati da Internet all'avvio. Ciò aumenta anche il tempo di avvio del sistema.

Apertura delle forme molto lunga

L'apertura prolungata dei moduli può essere dovuta a:

1. Un gran numero di controlli sul modulo: il tempo viene dedicato alla creazione del modulo e all'interconnessione della disposizione degli elementi del modulo;
2. Esecuzione di algoritmi durante l'inizializzazione del modulo. È possibile che durante la creazione del modulo vengano verificate alcune condizioni e/o letti gli oggetti correlati dal database.

Il primo problema viene “trattato” semplificando la forma. Ad esempio, alcuni controlli possono essere posizionati in moduli separati, il che può essere ancora più comodo per l'utente. Ad esempio, se il modulo ha un campo indirizzo "Città", "Via", "Casa", ecc., è meglio modificare l'indirizzo in un modulo separato.

Il secondo problema viene risolto analizzando le azioni eseguite durante la creazione e l'apertura di un modulo e ottimizzando questi algoritmi. Forse alcuni algoritmi sono già obsoleti, mentre altri possono essere semplificati e ottimizzati, ad esempio eliminando o minimizzando l'accesso ai dati nel database.

Come azione interattiva, considera l'utente che tenta di selezionare un valore su un elemento del modulo. In risposta a ciò, il sistema “pensa a qualcosa”. Ciò può accadere per i seguenti motivi:

1. Gli algoritmi eseguiti in questa azione esaminano o calcolano i dati associati che influenzano il comportamento di selezione del valore;
2. Il modulo di selezione che si apre per selezionare questo valore legge tutti gli oggetti dal database una volta inizializzato.

Per risolvere il primo problema, dovresti utilizzare la “Misurazione delle prestazioni”, trovare algoritmi ad alta intensità di risorse e ottimizzarli.

Il secondo problema può spesso essere risolto semplicemente analizzando l'implementazione del modulo di scelta. Ad esempio, dovresti assicurarti che la proprietà "Lettura dati dinamica" sia impostata per un elenco dinamico, che la proprietà "Tabella principale" sia impostata correttamente e che l'implementazione dell'elenco non utilizzi algoritmi ovviamente ad alta intensità di risorse.

Ci sono anche situazioni in cui, all'apertura del modulo di selezione, vengono letti alcuni dati correlati dal database (ad esempio, all'apertura del modulo di selezione “Articolo”, vengono letti i saldi delle merci nei magazzini). In genere questo non lo è soluzione migliore. È preferibile leggere i dati correlati in modo asincrono, dopo aver aperto il modulo. Ciò causerà meno disagio all'utente, perché Dopo che il modulo è stato visualizzato, l'utente trascorrerà un po' di tempo ad assorbire il modulo e questo tempo potrà essere impiegato caricando i dati correlati.

Risposta molto lunga agli aggiornamenti

Uno dei sintomi banali, tuttavia, può indicare alcuni problemi di sistema: l'aggiornamento 1C si blocca quando si avvia un backup. Ciò accade principalmente durante l'aggiornamento tramite Internet e, molto probabilmente, indica che la configurazione non è stata aggiornata per molto tempo e che i rilasci, susseguitisi uno dopo l'altro, hanno causato un blocco. Puoi prevenire un problema del genere installando gli aggiornamenti in modo tempestivo e, se lo riscontri, puoi semplicemente interrompere il processo di backup. Dopo aver avviato il configuratore, il database si avvierà con le modifiche apportate in modalità normale.

Va notato che 1C 8.3 si blocca molto spesso durante gli aggiornamenti anche perché richiede hardware più dispendioso in termini di risorse rispetto a versioni precedenti piattaforme. Vale la pena prestare attenzione alla quantità di RAM e, se necessario, aumentarla: questo, in linea di principio, dovrebbe aiutare a risolvere il problema "1C si blocca durante l'aggiornamento della configurazione".

Lungo processo di registrazione di oggetti/realizzazione di documenti

In questo caso il “trattamento basato sulla fotografia” è praticamente escluso, poiché le ragioni possono essere le più diverse, dalla grande quantità di dati nell'oggetto all'attesa alle serrature.

Ma anche in QUESTO caso è possibile delineare una direzione di analisi.

L'assenza di variazioni significative nel tempo di registrazione dovute all'ora del giorno o al numero di utenti (come stima approssimativa e soggettiva) indica un problema nel codice o nella quantità di dati dell'oggetto. Per l’analisi è opportuno utilizzare lo strumento “Misurazione delle prestazioni”.

Un cambiamento drammatico nel tempo di registrazione con dipendenze poco chiare richiede l'esecuzione di un'analisi statistica del verificarsi del problema, ad es. analisi delle prestazioni. Il modo più semplice è analizzare l'utilizzo del registro. Un ulteriore vantaggio è che la piattaforma 1C:Enterprise 8 supporta il salvataggio dei dati di registro in un file in formato SQLite. Ciò ti consentirà di utilizzare query SQL per analizzare i dati di registro. È del tutto possibile ottenere l'ora di scrittura dell'oggetto dai dati di registro, dato che ogni scrittura dell'oggetto viene eseguita in una transazione e ogni transazione ha il proprio numero di identificazione.

Se il risultato dell'analisi statistica ha mostrato che il tempo di registrazione di un oggetto dipende dall'ora del giorno e non dal numero di utenti, è necessario analizzare il carico sul server 1C e sul server del database. È possibile che il server stia eseguendo processi di routine che occupano risorse non necessarie.

Se il tempo necessario per scrivere gli oggetti dipende dal numero di utenti, il problema è molto probabilmente nel codice (probabilmente nell'attesa dei blocchi) o nel throughput dell'hardware. Per risolverli, dovresti coinvolgere uno specialista con la competenza “1C: Esperto in questioni tecnologiche", poiché non esistono regole unificate per risolvere un simile problema.