Picha na Alena Tulyakova, shirika la habari "Clerk.Ru"
Nakala hiyo inabainisha makosa kuu ambayo wasimamizi wa novice 1C hufanya na inaonyesha jinsi ya kuyatatua kwa kutumia jaribio la Gilev kama mfano.
Kusudi kuu la kuandika nakala hii ni kuzuia kurudia nuances dhahiri kwa wasimamizi hao (na waandaaji wa programu) ambao bado hawajapata uzoefu na 1C.
Lengo la pili ni kwamba ikiwa nina mapungufu yoyote, Infostart itakuwa ya haraka zaidi kunielezea hili.
Mtihani wa V. Gilev tayari umekuwa aina ya kiwango cha "de facto". Mwandishi kwenye wavuti yake alitoa mapendekezo wazi kabisa, lakini nitawasilisha matokeo kadhaa na kutoa maoni juu ya makosa yanayowezekana. Kwa kawaida, matokeo ya mtihani kwenye kifaa chako yanaweza kutofautiana; huu ni mwongozo tu wa kile kinachopaswa kuwa na kile unachoweza kujitahidi. Ningependa kutambua mara moja kwamba mabadiliko lazima yafanywe hatua kwa hatua, na baada ya kila hatua, angalia ni matokeo gani ilitoa.
Kuna nakala zinazofanana kwenye Infostart, nitaweka viungo kwao katika sehemu zinazofaa (ikiwa nimekosa kitu, tafadhali nipendekeze kwenye maoni, nitaongeza). Kwa hivyo, wacha tuchukue 1C yako ni polepole. Jinsi ya kutambua tatizo, na jinsi ya kuelewa ni nani wa kulaumiwa, msimamizi au programu?
Data ya awali:
Kompyuta iliyojaribiwa, nguruwe kuu ya Guinea: HP DL180G6, iliyo na 2 * Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Kwa kulinganisha, Core i3-2100 inaonyesha matokeo ya kulinganishwa katika mtihani wa thread moja. Vifaa nilivyochagua kimakusudi havikuwa vipya zaidi; kwa vifaa vya kisasa matokeo ni bora zaidi.
Kwa kupima seva tofauti za 1C na SQL, seva ya SQL: Mfumo wa IBM 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.
Ili kupima mtandao wa Gbit 10, adapta za Intel 520-DA2 zilitumiwa.
Toleo la faili. (database iko kwenye seva kwenye folda iliyoshirikiwa, wateja huunganisha kupitia mtandao, itifaki ya CIFS/SMB). Algorithm hatua kwa hatua:
0. Ongeza hifadhidata ya majaribio ya Gilev kwenye seva ya faili kwenye folda sawa na hifadhidata kuu. Tunaunganisha kutoka kwa kompyuta ya mteja na kukimbia mtihani. Tunakumbuka matokeo.
Inaeleweka kuwa hata kwa kompyuta za zamani kutoka miaka 10 iliyopita (Pentium kwenye tundu la 775), wakati kutoka kwa kubonyeza 1C: Njia ya mkato ya Biashara hadi kuonekana kwa dirisha la hifadhidata inapaswa kuchukua chini ya dakika. (Celeron = polepole).
Ikiwa kompyuta yako ni mbaya zaidi kuliko Pentium kwenye tundu la 775 na 1 GB ya RAM, basi ninakuhurumia, na itakuwa vigumu kwako kufikia kazi nzuri kwenye 1C 8.2 katika toleo la faili. Fikiria juu ya kuboresha (ni wakati mzuri) au kubadili kwenye terminal (au mtandao, katika kesi ya wateja nyembamba na fomu zinazosimamiwa) seva.
Ikiwa kompyuta sio mbaya zaidi, basi unaweza kumpiga msimamizi. Kwa kiwango cha chini, angalia uendeshaji wa mtandao, antivirus na dereva wa ulinzi wa HASP.
Ikiwa mtihani wa Gilev katika hatua hii ulionyesha "parrots" 30 au zaidi, lakini msingi wa kazi wa 1C bado unafanya kazi polepole, maswali yanapaswa kuelekezwa kwa programu.
1. Kama mwongozo wa ni kiasi gani kompyuta ya mteja inaweza "kubana", tunaangalia uendeshaji wa kompyuta hii tu, bila mtandao. Tunaweka hifadhidata ya majaribio kwenye kompyuta ya ndani (kwenye diski ya haraka sana). Ikiwa kompyuta ya mteja haina SSD ya kawaida, basi ramdisk imeundwa. Kwa sasa, moja rahisi na ya bure ni Ramdisk biashara.
Ili kujaribu toleo la 8.2, ramdisk ya 256 MB inatosha, na! Muhimu zaidi. Baada ya kuanzisha upya kompyuta, na ramdisk inayoendesha, inapaswa kuwa na 100-200 MB bure juu yake. Ipasavyo, bila ramdisk, kwa operesheni ya kawaida inapaswa kuwa na 300-400 MB ya kumbukumbu ya bure.
Ili kujaribu toleo la 8.3, ramdisk ya 256 MB inatosha, lakini unahitaji RAM zaidi ya bure.
Wakati wa kupima, unahitaji kuangalia mzigo wa processor. Katika hali iliyo karibu na bora (ramdisk), faili ya ndani 1c hupakia msingi 1 wa kichakataji wakati wa kukimbia. Ipasavyo, ikiwa wakati wa kujaribu msingi wa processor yako haijapakiwa kikamilifu, tafuta alama dhaifu. Kihisia kidogo, lakini kwa ujumla sahihi, ushawishi wa processor juu ya uendeshaji wa 1C umeelezwa. Kwa kumbukumbu tu, hata kwenye Core i3 za kisasa zilizo na masafa ya juu, nambari 70-80 ni za kweli kabisa.
Makosa ya kawaida katika hatua hii.
- Antivirus iliyosanidiwa vibaya. Kuna antivirus nyingi, mipangilio ya kila mmoja ni tofauti, nitasema tu kwamba kwa usanidi sahihi, wala mtandao wala Kaspersky 1C huingilia kati. Kwa mipangilio ya chaguo-msingi, takriban paroti 3-5 (10-15%) zinaweza kuchukuliwa.
- Hali ya utendaji. Kwa sababu fulani, watu wachache huzingatia hili, lakini athari ni muhimu zaidi. Ikiwa unahitaji kasi, basi lazima ufanye hivi, kwenye kompyuta za mteja na seva. (Gilev ana maelezo mazuri. Tahadhari pekee ni kwamba kwenye baadhi ya ubao wa mama, ukizima Intel SpeedStep, huwezi kuwasha TurboBoost).
Unaweza (na ikiwezekana) kuwezesha hali ya utendaji katika sehemu mbili:
- kupitia BIOS. Zima modi za C1, C1E, Intel C-state (C2, C3, C4). Katika bios tofauti huitwa tofauti, lakini maana ni sawa. Inachukua muda mrefu kutafuta, kuanzisha upya inahitajika, lakini ikiwa utafanya mara moja, basi unaweza kusahau. Ikiwa unafanya kila kitu kwa usahihi katika BIOS, kasi itaongezeka. Kwenye bodi zingine za mama, unaweza kusanidi mipangilio ya BIOS ili hali ya utendaji ya Windows isichukue jukumu. (Mifano ya mipangilio ya BIOS kutoka Gilev). Mipangilio hii inahusu wasindikaji wa seva au BIOS "ya hali ya juu", ikiwa haujapata hii na HUNA Xeon, ni sawa.
- Jopo la kudhibiti - Ugavi wa nguvu - Utendaji wa juu. Minus - ikiwa kompyuta haijahudumiwa kwa muda mrefu, itafanya kelele kubwa ya shabiki, joto zaidi na kutumia nishati zaidi. Hii ni ada ya utendaji.
| Hii ndio mipangilio chaguo-msingi. BIOS C-hali imewezeshwa, hali ya usawa ya matumizi ya nguvu |  |
| BIOS C-hali imewezeshwa, hali ya juu ya utendaji Kwa Pentium na Core unaweza kuacha hapo, Bado unaweza kubana "kasuku" kidogo kutoka kwa Xeon |  |
| Katika BIOS C-hali imezimwa, hali ya juu ya utendaji. Ikiwa hautumii Turbo boost, hii ndio inapaswa kuonekana kama seva iliyopangwa kwa utendaji |  |
Na sasa nambari. Acha nikukumbushe: Intel Xeon 5650, ramdisk. Katika kesi ya kwanza, mtihani unaonyesha 23.26, katika mwisho - 49.5. Tofauti ni karibu mara mbili. Nambari zinaweza kutofautiana, lakini uwiano unabaki sawa kwa Intel Core.
Wasimamizi wapendwa, unaweza kukosoa 1C upendavyo, lakini ikiwa watumiaji wa mwisho wanahitaji kasi, unahitaji kuwasha hali ya juu ya utendakazi.
c) Kuongeza Turbo. Kwanza unahitaji kuelewa ikiwa processor yako inasaidia kazi hii, kwa mfano. Ikiwa inasaidia, basi bado unaweza kupata utendaji fulani wa kisheria. (Sitaki kugusa maswala ya kuzidisha kwa mzunguko, haswa seva, fanya kwa hatari na hatari yako mwenyewe. Lakini ninakubali kwamba kuongeza kasi ya Basi kutoka 133 hadi 166 kunatoa ongezeko kubwa la kasi na utaftaji wa joto)
Jinsi ya kuwasha turbo boost imeandikwa, kwa mfano,. Lakini! Kwa 1C kuna baadhi ya nuances (sio wazi zaidi). Ugumu ni kwamba athari ya juu ya kuongeza turbo hutokea wakati C-state imewashwa. Na tunapata kitu kama hiki:
Tafadhali kumbuka kuwa kizidisha ni cha juu, kasi ya Core ni nzuri, na utendaji ni wa juu. Lakini nini kitatokea kama matokeo na 1s?
Lakini mwishowe zinageuka kuwa kulingana na vipimo vya utendaji wa CPU toleo na kizidishi cha 23 liko mbele, kulingana na vipimo vya Gilev katika toleo la faili utendaji na kiongeza cha 22 na 23 ni sawa, lakini katika seva ya mteja. toleo - toleo lenye kizidishi cha 23 ni la kutisha sana (hata kama hali ya C imewekwa kwa kiwango cha 7, bado ni polepole kuliko hali ya C imezimwa). Kwa hivyo, pendekezo ni kuangalia chaguzi zote mbili kwako na uchague bora zaidi. Kwa hali yoyote, tofauti kati ya parrots 49.5 na 53 ni muhimu sana, hasa bila jitihada nyingi.
Hitimisho - nyongeza ya turbo lazima iwashwe. Acha nikukumbushe kuwa haitoshi kuwezesha kipengee cha kuongeza Turbo kwenye BIOS, unahitaji pia kuangalia mipangilio mingine (BIOS: QPI L0s, L1 -lemaza, hitaji kusugua -lemaza, Intel SpeedStep - wezesha, kuongeza Turbo - wezesha Paneli Kidhibiti - Chaguzi za Nguvu - Utendaji wa Juu) . Na bado ningechagua (hata kwa toleo la faili) chaguo ambapo c-state imezimwa, ingawa kizidishi ni kidogo. Itatokea kitu kama hiki ...
Jambo lenye utata ni masafa ya kumbukumbu. Kwa mfano, mzunguko wa kumbukumbu unaonyeshwa kuwa na ushawishi mkubwa sana. Vipimo vyangu havikuonyesha utegemezi kama huo. Sitalinganisha DDR 2/3/4, nitaonyesha matokeo ya kubadilisha mzunguko ndani ya mstari huo. Kumbukumbu ni sawa, lakini katika BIOS tunalazimika kuweka masafa ya chini.
 |  |  |
Na matokeo ya mtihani. 1C 8.2.19.83, kwa toleo la faili la ramdisk ya ndani, kwa seva ya mteja 1C na SQL kwenye kompyuta moja, Kumbukumbu iliyoshirikiwa. Turbo boost imezimwa katika matoleo yote mawili. 8.3 inaonyesha matokeo linganifu.
Tofauti iko ndani ya kosa la kipimo. Nilitoa picha za skrini za CPU-Z ili kuonyesha kuwa kwa mabadiliko ya frequency, vigezo vingine pia hubadilika, CAS Latency sawa na RAS hadi Kucheleweshwa kwa CAS, ambayo hubadilisha mabadiliko ya frequency. Tofauti itakuwa wakati moduli za kumbukumbu zinabadilishwa kimwili, kutoka kwa polepole hadi kwa kasi, lakini hata huko nambari sio muhimu sana.
2. Tunapopanga processor na kumbukumbu ya kompyuta ya mteja, tunaendelea hadi mahali muhimu sana - mtandao. Vitabu vingi vimeandikwa juu ya kutengeneza mtandao, kuna nakala kwenye Infostart (, na zingine), lakini hapa sitazingatia mada hii. Kabla ya kuanza kujaribu 1C, tafadhali hakikisha kuwa iperf kati ya kompyuta mbili inaonyesha kipimo data kizima (kwa kadi 1 za Gbit - vizuri, angalau 850 Mbit, au bora zaidi 950-980), kwamba ushauri wa Gilev umefuatwa. Kisha - mtihani rahisi zaidi wa operesheni itakuwa, isiyo ya kawaida, kuiga faili moja kubwa (5-10 gigabytes) kwenye mtandao. Ishara isiyo ya moja kwa moja ya operesheni ya kawaida kwenye mtandao wa Gbit 1 itakuwa kasi ya wastani ya kunakili ya 100 MB/sec, operesheni nzuri - 120 MB/sec. Ningependa kuteka mawazo yako kwa ukweli kwamba hatua dhaifu (ikiwa ni pamoja na) inaweza kuwa mzigo wa processor. Itifaki ya SMB kwenye Linux haijalinganishwa vibaya, na wakati wa operesheni inaweza "kula" msingi mmoja wa processor na usitumie tena.
Na zaidi. Na mipangilio chaguo-msingi, mteja wa windows hufanya kazi vyema na seva ya windows (au hata kituo cha kazi cha windows) na itifaki ya SMB/CIFS, mteja wa linux (debian, ubuntu hakuangalia zingine) hufanya kazi vyema na linux na NFS ( pia inafanya kazi na SMB, lakini kwenye kasuku za NFS ni ndefu zaidi). Ukweli kwamba wakati wa kunakili kwa mstari seva ya Windows Linux kwa NFS inakiliwa kwenye mkondo mmoja haraka haimaanishi chochote. Urekebishaji wa Debian kwa 1C ni mada ya nakala tofauti, siko tayari kwa hiyo bado, ingawa naweza kusema kwamba katika toleo la faili nilipata utendaji bora zaidi kuliko toleo la Win kwenye vifaa sawa, lakini na postgres zilizo na zaidi. Watumiaji 50 bado nina kila kitu kibaya sana.
Jambo muhimu zaidi ambalo wasimamizi "walichomwa" wanajua, lakini wanaoanza hawazingatii. Kuna njia nyingi za kuweka njia ya hifadhidata ya 1c. Unaweza kufanya servershare, unaweza kufanya 192.168.0.1share, unaweza kutumia z: 192.168.0.1share (na katika hali nyingine njia hii pia itafanya kazi, lakini si mara zote) na kisha kutaja gari Z. Inaonekana kwamba njia hizi zote elekeza kwa kitu kile kile mahali sawa, lakini kwa 1C kuna njia moja tu ambayo hutoa utendaji wa kawaida kwa uhakika kabisa. Kwa hivyo, hii ndio unahitaji kufanya kwa usahihi:
Kwenye mstari wa amri (au katika sera, au chochote kinachofaa kwako) - tumia DriveLetter: servershare. Mfano: wavu matumizi m: serverbases. Ninasisitiza haswa SI anwani ya IP, lakini jina la seva. Ikiwa jina la seva halionekani, liongeze kwa dns kwenye seva, au ndani ya faili ya mwenyeji. Lakini anwani lazima iwe kwa jina. Ipasavyo, kwenye njia ya hifadhidata, fikia diski hii (tazama picha).
Na sasa nitaonyesha na nambari kwa nini huu ndio ushauri. Data ya awali: Intel X520-DA2, Intel 362, Intel 350, Kadi za Realtek 8169. OS Win 2008 R2, Win 7, Debian 8. Viendeshi vya hivi karibuni, masasisho yametumika. Kabla ya kupima, nilihakikisha kwamba Iperf inatoa bandwidth kamili (isipokuwa kwa kadi 10 za Gbit, iliweza tu kufinya 7.2 Gbit, nitaona kwa nini baadaye, seva ya majaribio bado haijasanidiwa vizuri). Disks ni tofauti, lakini kila mahali kuna SSD (mimi hasa niliingiza diski moja kwa ajili ya kupima, haijapakiwa na kitu kingine chochote) au uvamizi kutoka kwa SSD. Kasi ya 100 Mbit ilipatikana kwa kupunguza mipangilio ya adapta ya Intel 362. Hakukuwa na tofauti kati ya 1 Gbit shaba Intel 350 na 1 Gbit macho Intel X520-DA2 (iliyopatikana kwa kupunguza kasi ya adapta). Utendaji wa juu zaidi, nyongeza ya turbo imezimwa (kwa ulinganifu tu wa matokeo, turbo boost kwa matokeo mazuri huongeza kidogo chini ya 10%, kwa matokeo mabaya inaweza kuwa na athari yoyote). Matoleo ya 1C 8.2.19.86, 8.3.6.2076. Sitoi nambari zote, lakini zile zinazovutia zaidi, ili uwe na kitu cha kulinganisha.
| 100 Mbit CIFS Shinda 2008 - Shinda 2008 wasiliana na anwani ya ip | 100 Mbit CIFS Shinda 2008 - Shinda 2008 kuita kwa jina | CIFS ya Gbit 1 Shinda 2008 - Shinda 2008 wasiliana na anwani ya ip | CIFS ya Gbit 1 Shinda 2008 - Shinda 2008 kuita kwa jina | CIFS ya Gbit 1 Shinda 2008 - Shinda 7 kuita kwa jina | CIFS ya Gbit 1 Shinda 2008 - Debian kuita kwa jina | 10 Gbit CIFS Shinda 2008 - Shinda 2008 wasiliana na anwani ya ip | 10 Gbit CIFS Shinda 2008 - Shinda 2008 kuita kwa jina |
|
| 11,20 | 26,18 | 15,20 | 43,86 | 40,65 | 37,04 | 16,23 | 44,64 | |
| 1C 8.2 | 11,29 | 26,18 | 15,29 | 43,10 | 40,65 | 36,76 | 15,11 | 44,10 |
| 8.2.19.83 | 12,15 | 25,77 | 15,15 | 43,10 | 14,97 | 42,74 | ||
| 6,13 | 34,25 | 14,98 | 43,10 | 39,37 | 37,59 | 15,53 | 42,74 | |
| 1C 8.3 | 6,61 | 33,33 | 15,58 | 43,86 | 40,00 | 37,88 | 16,23 | 42,74 |
| 8.3.6.2076 | 33,78 | 15,53 | 43,48 | 39,37 | 37,59 | 42,74 |
Hitimisho (kutoka kwa jedwali na kutoka kwa uzoefu wa kibinafsi. Inatumika kwa toleo la faili pekee):
- Kwenye mtandao, unaweza kupata nambari za kawaida za kazi ikiwa mtandao huu umeundwa vizuri na njia imeingizwa kwa usahihi katika 1C. Hata Core i3 ya kwanza inaweza kuzalisha parrots 40+ kwa urahisi, ambayo ni nzuri kabisa, na haya sio tu parrots, katika kazi halisi tofauti pia inaonekana. Lakini! Kizuizi wakati wa kufanya kazi na watumiaji kadhaa (zaidi ya 10) hawatakuwa tena mtandao, hapa 1 Gbit bado ni ya kutosha, lakini kuzuia wakati wa kazi ya watumiaji wengi (Gilev).
- jukwaa la 1C 8.3 linahitajika mara nyingi zaidi katika suala la usanidi sahihi wa mtandao. Mipangilio ya msingi - tazama Gilev, lakini kumbuka kwamba kila kitu kinaweza kuathiriwa. Niliona kuongeza kasi kutoka kwa kufuta (na sio tu kuzima) antivirus, kutoka kwa kuondoa itifaki kama FCoE, kutoka kwa kubadilisha madereva hadi ya zamani, lakini toleo la kuthibitishwa la Microsoft (haswa kwa kadi za bei nafuu kama ASUS na DLC), kutoka kwa kuondoa kadi ya pili ya mtandao. kutoka kwa seva. Kuna chaguzi nyingi, weka mtandao wako kwa uangalifu. Kunaweza kuwa na hali ambapo jukwaa 8.2 linatoa nambari zinazokubalika, na 8.3 - mara mbili au zaidi chini. Jaribu kucheza na matoleo ya jukwaa 8.3, wakati mwingine unapata athari kubwa sana.
- 1C 8.3.6.2076 (labda baadaye, sijatafuta toleo kamili bado) bado ni rahisi kusanidi kwenye mtandao kuliko 8.3.7.2008. Niliweza kufikia operesheni ya kawaida kwenye mtandao kutoka 8.3.7.2008 (katika parrots kulinganishwa) mara chache tu; Sikuweza kurudia kwa kesi ya jumla zaidi. Sikuelewa mengi, lakini kwa kuzingatia vifuniko vya mguu kutoka kwa Mchakato wa Kuchunguza, kurekodi huko sio nzuri kama katika 8.3.6.
- Licha ya ukweli kwamba wakati wa kufanya kazi kwenye mtandao wa 100 Mbit, ratiba yake ya mzigo ni ndogo (tunaweza kusema kwamba mtandao ni bure), kasi ya uendeshaji bado ni ndogo sana kuliko 1 Gbit. Sababu ni kuchelewa kwa mtandao.
- Vitu vingine vyote vikiwa sawa (mtandao unaofanya kazi vizuri) kwa 1C 8.2 muunganisho wa Intel-Realtek ni polepole 10% kuliko Intel-Intel. Lakini realtek-realtek kwa ujumla inaweza kutoa utulivu mkali nje ya bluu. Kwa hivyo, ikiwa una pesa, ni bora kuweka kadi za mtandao za Intel kila mahali; ikiwa huna pesa, basi usakinishe Intel tu kwenye seva (CO yako). Na kuna maagizo mara nyingi zaidi ya kurekebisha kadi za mtandao za Intel.
- Mipangilio chaguomsingi ya antivirus (kwa kutumia toleo la 10 la drweb) inachukua takriban 8-10% ya kasuku. Ikiwa utaisanidi inavyopaswa (ruhusu mchakato wa 1cv8 kufanya kila kitu, ingawa sio salama), kasi ni sawa na bila antivirus.
- Usisome gurus za Linux. Seva iliyo na samba ni nzuri na ya bure, lakini ikiwa utasanikisha Win XP au Win7 (au hata bora - seva OS) kwenye seva, basi toleo la faili la 1c litafanya kazi kwa kasi zaidi. Ndio, samba na mpangilio wa itifaki na mipangilio ya mtandao na mengi, mengi zaidi yanaweza kupangwa vizuri katika debian/ubuntu, lakini hii inapendekezwa kwa wataalamu. Hakuna maana katika kusakinisha Linux na mipangilio chaguo-msingi na kisha kusema kwamba ni polepole.
- Ni wazo nzuri kuangalia utendakazi wa diski zilizounganishwa kupitia matumizi ya wavu kwa kutumia fio . Angalau itakuwa wazi ikiwa haya ni matatizo na jukwaa la 1C, au na mtandao/diski.
- Kwa toleo la mtumiaji mmoja, siwezi kufikiria majaribio (au hali) ambapo tofauti kati ya 1 Gbit na 10 Gbit ingeonekana. Kitu pekee ambacho 10Gbit kwa toleo la faili ilitoa matokeo bora ni kuunganisha diski kupitia iSCSI, lakini hii ni mada ya nakala tofauti. Bado, nadhani kwamba kwa toleo la faili kadi za Gbit 1 zinatosha.
- Sielewi kwa nini, kwa mtandao wa 100 Mbit, 8.3 inafanya kazi kwa kasi zaidi kuliko 8.2, lakini ilikuwa ukweli. Vifaa vingine vyote, mipangilio mingine yote ni sawa kabisa, ni kwamba katika kesi moja 8.2 inajaribiwa, na kwa nyingine - 8.3.
- NFS isiyo na mpangilio ya kushinda-kushinda au kushinda-lin inatoa parrots 6, sikuwajumuisha kwenye meza. Baada ya kurekebisha nilipata 25, lakini haikuwa thabiti (tofauti ya vipimo ilikuwa zaidi ya vitengo 2). Bado siwezi kutoa mapendekezo ya kutumia Windows na itifaki ya NFS.
Seva ya terminal. (database iko kwenye seva, wateja huunganisha kupitia mtandao, itifaki ya RDP). Algorithm hatua kwa hatua:
- Tunaongeza hifadhidata ya mtihani wa Gilev kwenye seva kwenye folda sawa na hifadhidata kuu. Tunaunganisha kutoka kwa seva sawa na kukimbia mtihani. Tunakumbuka matokeo.
- Kwa njia sawa na katika toleo la faili, tunasanidi processor. Kwa upande wa seva ya wastaafu, processor kwa ujumla ina jukumu kuu (inadhaniwa kuwa hakuna pointi dhaifu, kama vile ukosefu wa kumbukumbu au kiasi kikubwa cha programu isiyo ya lazima).
- Kusanidi kadi za mtandao katika kesi ya seva ya terminal haina athari yoyote kwa uendeshaji wa 1c. Ili kuhakikisha faraja "maalum", ikiwa seva yako inazalisha parrots zaidi ya 50, unaweza kucheza na matoleo mapya ya itifaki ya RDP, kwa ajili ya faraja ya watumiaji, majibu ya haraka na kusonga.
- Wakati idadi kubwa ya watumiaji wanafanya kazi kikamilifu (na hapa unaweza tayari kujaribu kuunganisha watu 30 kwenye database moja, ukijaribu), inashauriwa sana kufunga gari la SSD. Kwa sababu fulani, inaaminika kuwa disk haiathiri hasa uendeshaji wa 1C, lakini vipimo vyote vinafanywa na cache ya mtawala iliyowezeshwa kwa kuandika, ambayo si sahihi. Msingi wa mtihani ni mdogo, unafaa kabisa kwenye cache, kwa hiyo namba za juu. Kwenye hifadhidata halisi (kubwa) kila kitu kitakuwa tofauti kabisa, kwa hivyo kache imezimwa kwa majaribio.
| Uvamizi 10 4x SATA 7200 ATA ST31500341AS | Uvamizi 10 4x SAS 10k | Uvamizi 10 4x SAS 15k | SSD moja | Ramdisk | Ramdisk | Akiba imewashwa Kidhibiti cha RAID |
|
| 21,74 | 28,09 | 32,47 | 49,02 | 50,51 | 53,76 | 49,02 | |
| 1C 8.2 | 21,65 | 28,57 | 32,05 | 48,54 | 49,02 | 53,19 | |
| 8.2.19.83 | 21,65 | 28,41 | 31,45 | 48,54 | 49,50 | 53,19 | |
| 33,33 | 42,74 | 45,05 | 51,55 | 52,08 | 55,56 | 51,55 | |
| 1C 8.3 | 33,46 | 42,02 | 45,05 | 51,02 | 52,08 | 54,95 | |
| 8.3.7.2008 | 35,46 | 43,01 | 44,64 | 51,55 | 52,08 | 56,18 |
- Kashe ya kidhibiti cha RAID iliyowezeshwa huondoa tofauti zote kati ya diski; nambari ni sawa kwa sat na cas. Kujaribu nayo kwa kiasi kidogo cha data haina maana na sio dalili ya aina yoyote.
- Kwa jukwaa 8.2, tofauti katika utendaji kati ya chaguzi za SATA na SSD ni zaidi ya mara mbili. Hii si typo. Ikiwa unatazama ufuatiliaji wa utendaji wakati wa mtihani kwenye anatoa za SATA. basi unaweza kuona wazi "Wakati wa uendeshaji wa disk Active (katika%)" 80-95. Ndiyo, ikiwa unawezesha cache ya disks wenyewe kwa kurekodi, kasi itaongezeka hadi 35, ikiwa utawezesha cache ya mtawala wa uvamizi - hadi 49 (bila kujali ni disks gani zinazojaribiwa kwa sasa). Lakini hizi ni kasuku za kache za syntetisk; katika kazi halisi, na hifadhidata kubwa, hakutakuwa na uwiano wa 100% wa kuandika kache.
- Kasi ya SSD za bei nafuu (nilijaribu kwenye Agility 3) inatosha kuendesha toleo la faili. Rasilimali ya kurekodi ni jambo lingine, unahitaji kuiangalia katika kila kesi maalum, ni wazi kwamba Intel 3700 itakuwa na utaratibu wa ukubwa wa juu, lakini bei inafanana. Na ndiyo, ninaelewa kwamba wakati wa kupima diski ya SSD, ninajaribu pia cache ya diski hii kwa kiasi kikubwa, matokeo halisi yatakuwa chini.
- Suluhisho sahihi zaidi (kutoka kwa maoni yangu) litakuwa kutenga diski 2 za SSD katika uvamizi ulioakisiwa kwa hifadhidata ya faili (au hifadhidata kadhaa za faili), na sio kuweka kitu kingine chochote hapo. Ndio, na kioo, SSD huvaa kwa usawa, na hii ni minus, lakini angalau vifaa vya elektroniki vya mtawala vinalindwa kutokana na makosa.
- Faida kuu za anatoa SSD kwa toleo la faili itaonekana wakati kuna hifadhidata nyingi, kila moja na watumiaji kadhaa. Ikiwa kuna hifadhidata 1-2, na kuna watumiaji wapatao 10, basi diski za SAS zitatosha. (lakini kwa hali yoyote, angalia upakiaji wa diski hizi, angalau kupitia perfmon).
- Faida kuu za seva ya terminal ni kwamba inaweza kuwa na wateja dhaifu sana, na mipangilio ya mtandao huathiri seva ya wastaafu (tena, K.O. yako).
Ikiwa mtihani wa Gilev unaonyesha nambari ndogo, na una processor ya saa ya juu na disks za haraka, basi msimamizi anahitaji kuchukua angalau perfmon, kurekodi matokeo yote mahali fulani, na kuangalia, kuchunguza, na kuteka hitimisho. Hakutakuwa na ushauri wa uhakika.
Chaguo la seva ya mteja.
Uchunguzi ulifanyika tu tarehe 8.2, kwa sababu mnamo 8.3 kila kitu kinategemea sana toleo hilo.
Kwa majaribio, nilichagua chaguzi tofauti za seva na mitandao kati yao ili kuonyesha mitindo kuu.
| 1C: Xeon 5520 SQL: Xeon E5-2630 | 1C: Xeon 5520 SQL: Xeon E5-2630 Njia ya nyuzi - SSD | 1C: Xeon 5520 SQL: Xeon E5-2630 Njia ya nyuzi - SAS | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 SQL: Xeon E5-2630 Njia ya nyuzi - SSD | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | 1C: Xeon 5650 = | |
| 16,78 | 18,23 | 16,84 | 28,57 | 27,78 | 32,05 | 34,72 | 36,50 | 23,26 | 40,65 | 39.37 | |
| 1C 8.2 | 17,12 | 17,06 | 14,53 | 29,41 | 28,41 | 31,45 | 34,97 | 36,23 | 23,81 | 40,32 | 39.06 |
| 16,72 | 16,89 | 13,44 | 29,76 | 28,57 | 32,05 | 34,97 | 36,23 | 23,26 | 40,32 | 39.06 |
Inaonekana kwamba nimezingatia chaguzi zote za kuvutia, ikiwa kuna kitu kingine chochote unachopenda, andika kwenye maoni, nitajaribu kufanya hivyo.
- SAS kwenye mifumo ya uhifadhi ni polepole kuliko SSD za ndani, ingawa mifumo ya uhifadhi ina saizi kubwa za kache. SSD, za ndani na kwenye mifumo ya uhifadhi, hufanya kazi kwa kasi inayolingana kwa mtihani wa Gilev. Sijui mtihani wowote wa kawaida wa nyuzi nyingi (sio kurekodi tu, lakini vifaa vyote) isipokuwa kwa jaribio la upakiaji wa 1C kutoka kwa MCC.
- Kubadilisha seva ya 1C kutoka 5520 hadi 5650 karibu mara mbili ya utendaji. Ndiyo, usanidi wa seva haufanani kabisa, lakini inaonyesha mwenendo (hakuna mshangao).
- Kuongeza frequency kwenye seva ya SQL hakika kunatoa athari, lakini sio sawa na kwenye seva ya 1C; Seva ya MS SQL ni bora (ikiwa utaiuliza) kutumia cores nyingi na kumbukumbu ya bure.
- Kubadilisha mtandao kati ya 1C na SQL kutoka Gbit 1 hadi Gbit 10 hutoa takriban 10% ya kasuku. Nilitarajia zaidi.
- Kuwasha Kumbukumbu iliyoshirikiwa bado kunatoa athari, ingawa sio 15%, kama ilivyoelezewa kwenye kifungu. Hakikisha kuifanya, kwa bahati nzuri ni haraka na rahisi. Ikiwa wakati wa usakinishaji mtu aliipa seva ya SQL mfano uliotajwa, basi ili 1C ifanye kazi, jina la seva lazima libainishwe sio na FQDN (tcp/ip itafanya kazi), sio kupitia localhost au ServerName tu, lakini kupitia ServerNameInstanceName, kwa mfano zz- testzztest. (Vinginevyo kutakuwa na hitilafu ya DBMS: Mteja Asilia wa Seva ya Microsoft SQL 10.0: Mtoa Kumbukumbu Inayoshirikiwa: Maktaba ya kumbukumbu iliyoshirikiwa iliyotumiwa kuanzisha muunganisho na SQL Server 2000 haikupatikana. HRESULT=80004005, HRESULT=80004005, HRESULTSRESULTr=80004005, : SQLSTATE=08001, state=1, Severity=10, native=126, line=0).
- Kwa watumiaji chini ya 100, hatua pekee ya kuigawanya katika seva mbili tofauti ni leseni ya Win 2008 Std (na zaidi), ambayo inasaidia tu 32GB ya RAM. Katika visa vingine vyote, 1C na SQL hakika zinahitaji kusakinishwa kwenye seva moja na kupewa kumbukumbu zaidi (angalau 64 GB). Kutoa MS SQL chini ya 24-28 GB ya RAM ni uchoyo usio na msingi (ikiwa unafikiri kuwa una kumbukumbu ya kutosha kwake na kila kitu kinafanya kazi vizuri, labda toleo la faili la 1C lingekutosha?)
- Jinsi mbaya zaidi mchanganyiko wa 1C na SQL hufanya kazi kwenye mashine ya kawaida ni mada ya nakala tofauti (dokezo - mbaya zaidi). Hata katika Hyper-V kila kitu sio wazi ...
- Hali ya utendaji iliyosawazishwa ni mbaya. Matokeo yanaendana kabisa na toleo la faili.
- Vyanzo vingi vinasema kuwa hali ya kurekebisha (ragent.exe -debug) husababisha kupungua kwa kiasi kikubwa kwa utendaji. Naam, inapunguza, ndiyo, lakini singeita 2-3% athari kubwa.
Mara nyingi watu huja kwetu na maswali kama vile:
- Kwa nini seva ya 1C inapunguza kasi?
- Kompyuta ya 1C ni polepole sana
- 1C mteja ni polepole sana
Wakati mwingine, kama suluhisho la suala hili, tunawapa wateja seva ya 1C kwa kukodisha bila breki, na chaguo la usanidi wa seva na mfumo wa uendeshaji, unaweza kusanidi seva mtandaoni kwenye tovuti ya mshirika wetu, kwa kutumia kiungo. https://1cloud.ru sura Huduma, sura Seva pepe.
Nini cha kufanya na jinsi ya kuishinda, na kadhalika kwa mpangilio:
Wateja hufanya kazi polepole sana na toleo la seva la 1C
Mbali na kazi ya polepole ya 1C, pia kuna kazi ya polepole na faili za mtandao. Tatizo hutokea wakati wa operesheni ya kawaida na kwa RDP
kutatua hili, baada ya kila usakinishaji wa Saba au seva ya 2008, mimi huanza kila wakati
netsh int tcp set global autotuning=disabled
netsh int tcp imeweka global autotuninglevel=imezimwa
netsh int tcp set global rss=dibled chimney=imezimwa
na mtandao hufanya kazi bila matatizo
wakati mwingine chaguo bora ni:
netsh interface tcp set global autotuning= HighlyRestricted
hivi ndivyo usakinishaji unavyoonekana
Sanidi Anti-Virus au Windows firewall
Jinsi ya kusanidi Anti-Virus au Windows firewall kwa ajili ya kuendesha seva ya 1C (mchanganyiko wa 1C Server: Enterprise na MS SQL 2008, kwa mfano).
Ongeza sheria:
- Ikiwa seva ya SQL inakubali miunganisho kwenye bandari ya kawaida ya TCP 1433, basi tunairuhusu.
- Ikiwa lango la SQL linabadilika, basi lazima uruhusu miunganisho kwa %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.exe.
- Seva 1C inaendeshwa kwenye bandari 1541, nguzo 1540 na safu 1560-1591. Kwa sababu za fumbo kabisa, wakati mwingine orodha kama hiyo ya bandari wazi bado hairuhusu miunganisho kwenye seva. Ili kuhakikisha kuwa inafanya kazi, ruhusu anuwai 1540-1591.
Urekebishaji wa utendaji wa Seva/Kompyuta
Ili kompyuta yako ifanye kazi kwa kiwango cha juu, unahitaji kuisanidi kwa hili:
1. Mipangilio ya BIOS
- Katika BIOS ya seva, tunazima mipangilio yote ili kuokoa nguvu ya processor.
- Ikiwa kuna "C1E" na hakikisha UMEKATA!
- Kwa baadhi ya kazi zisizo sawa, inashauriwa pia kuzima biashara ya hypertrading katika BIOS
- Katika baadhi ya matukio (hasa kwa HP!) Unahitaji kwenda kwenye BIOS ya seva na KUZIMA vitu vilivyo na EIST, Intel SpeedStep na C1E kwa majina yao.
- Badala yake, unahitaji kupata vipengee vinavyohusiana na kichakataji hapo ambavyo vina Turbo Boost katika majina yao, na UWAWEZE.
- Ikiwa katika BIOS kuna dalili ya jumla ya hali ya kuokoa nguvu na uijumuishe katika hali ya juu ya utendaji (inaweza pia kuitwa "fujo")
2. Mipangilio ya mpango katika mfumo wa uendeshaji - Utendaji wa juu
Seva zilizo na usanifu wa Intel Sandy Bridge zinaweza kubadilisha masafa ya kichakataji.
Wakati mwingine suluhisho la shida ya utendakazi polepole wa seva ya 1C imepitwa na wakati au vifaa vilivyovunjika, katika kesi hii tunawapa wateja seva ya 1C kwa kukodisha bila breki, na chaguo la usanidi wa seva na mfumo wa uendeshaji, unaweza kuifanya kwenye yetu. tovuti ya washirika, kwenye kiungo https://1cloud.ru Sehemu ya huduma, sehemu ya seva pepe.
Ikiwa una maswali yoyote tafadhali wasiliana na:
- piga simu +7-812-385-55-66 huko St
- andika kwa anwani
- acha maombi kwenye tovuti yetu kwenye ukurasa wa "Online application".
Mfumo wa 1C unachukua nafasi kubwa katika soko la otomatiki kwa biashara ndogo na za kati. Ikiwa kampuni imechagua mfumo wa uhasibu wa 1C, basi kawaida karibu wafanyakazi wote hufanya kazi ndani yake, kutoka kwa wataalamu wa kawaida hadi usimamizi. Ipasavyo, kasi ya michakato ya biashara ya kampuni inategemea kasi ya 1C. Ikiwa 1C inafanya kazi kwa kasi isiyo ya kuridhisha, basi hii inathiri moja kwa moja kazi ya kampuni nzima na faida.
Kweli ipo Njia tatu za kuongeza kasi ya 1C:
- Kuongezeka kwa uwezo wa vifaa.
- Uboreshaji wa mfumo wa uendeshaji na mipangilio ya DBMS.
- Uboreshaji wa kanuni na algoriti katika 1C.
Njia ya kwanza inahitaji ununuzi wa vifaa na leseni, ya tatu inahitaji kazi nyingi kwa waandaaji wa programu na, kwa sababu hiyo, njia zote mbili husababisha gharama kubwa za kifedha. Kwanza kabisa, unahitaji kulipa kipaumbele kwa msimbo wa programu, kwa kuwa hakuna ongezeko la uwezo wa seva linaweza kulipa fidia kwa msimbo usio sahihi. Msanidi programu yeyote anajua kuwa kwa mistari michache tu ya nambari inawezekana kuunda mchakato ambao utapakia kabisa rasilimali za seva yoyote.
Ikiwa kampuni ina uhakika kwamba msimbo wa programu ni mojawapo, lakini bado inafanya kazi polepole, usimamizi kawaida huamua kuongeza uwezo wa seva. Katika hatua hii, swali la kimantiki linatokea: ni nini kinakosekana, ni kiasi gani na nini kinahitaji kuongezwa mwisho.
Kampuni ya 1C inatoa jibu lisilo wazi kwa swali la ni rasilimali ngapi zinahitajika; tuliandika juu yake mapema katika machapisho yetu. Na kwa hivyo, lazima ufanye majaribio kwa uhuru na ujue ni nini utendaji wa 1C unategemea. Majaribio ya utendaji wa programu katika EFSOL yameelezwa hapa chini.
Wakati wa kufanya kazi na 1C 8.2, haswa na usanidi unaotumia fomu zilizosimamiwa, ukweli wa kushangaza uligunduliwa: 1C inafanya kazi haraka kwenye kituo cha kazi kuliko kwenye seva yenye nguvu. Kwa kuongeza, sifa zote za kituo cha kazi ni mbaya zaidi kuliko za seva.
Jedwali 1 - Mipangilio ambayo majaribio ya awali yalifanyika
Kituo cha kazi kinaonyesha utendakazi 155% zaidi kuliko seva ya 1C yenye sifa bora. Tulianza kujua nini kinaendelea na kupunguza msako.
Kielelezo 1 - Vipimo vya utendaji kwenye kituo cha kazi kwa kutumia mtihani wa Gilev
Tuhuma ya kwanza ilikuwa kwamba mtihani wa Gilev haukuwa wa kutosha. Vipimo vya fomu za kufungua, kuchapisha nyaraka, ripoti za kuzalisha, nk kwa kutumia zana za zana zilionyesha kuwa mtihani wa Gilev hutoa tathmini ya uwiano na kasi halisi ya kazi katika 1C.
Nambari na mzunguko wa RAM
Mchanganuo wa habari inayopatikana kwenye Mtandao ulionyesha kuwa wengi wanaandika juu ya utegemezi wa utendaji wa 1C kwenye mzunguko wa kumbukumbu. Inategemea mzunguko, si kwa kiasi. Tuliamua kupima hypothesis hii, kwa kuwa tuna mzunguko wa RAM wa 1066 Mhz kwenye seva dhidi ya 1333 Mhz kwenye kituo cha kazi, na kiasi cha RAM kwenye seva tayari ni cha juu zaidi. Tuliamua kufunga mara moja sio 1066 Mhz, lakini 800 Mhz ili athari ya utegemezi wa utendaji kwenye mzunguko wa kumbukumbu iwe wazi zaidi. Matokeo yake ni kwamba tija ilishuka kwa 12% na kufikia vitengo 39.37. Tuliweka kumbukumbu na mzunguko wa 1333 Mhz badala ya 1066 Mhz kwenye seva na kupokea ongezeko kidogo la utendaji - karibu 11%. Uzalishaji ulikuwa vitengo 19.53. Ipasavyo, sio suala la kumbukumbu, ingawa frequency yake inatoa ongezeko kidogo.
Kielelezo 2 - Vipimo vya utendaji kwenye kituo cha kazi baada ya kupunguza mzunguko wa RAM
Kielelezo 3 - Vipimo vya utendaji kwenye seva baada ya kuongeza mzunguko wa RAM
Mfumo mdogo wa diski
Dhana iliyofuata ilihusiana na mfumo mdogo wa diski. Mawazo mawili yaliibuka mara moja:
- SSD ni bora kuliko viendeshi vya SAS, hata kama ziko katika uvamizi 10.
- iSCSI ni polepole au si sahihi.
Kwa hiyo, disk ya kawaida ya SATA iliwekwa kwenye kituo cha kazi badala ya SSD, na sawa ilifanyika na seva - database iliwekwa kwenye diski ya SATA ya ndani. Matokeo yake, vipimo vya utendaji havikubadilika kabisa. Uwezekano mkubwa zaidi, hii hutokea kwa sababu kuna kiasi cha kutosha cha RAM na disks ni kivitendo si kushiriki kwa njia yoyote wakati wa mtihani.
CPU
Wasindikaji kwenye seva ni, bila shaka, wenye nguvu zaidi na kuna wawili wao, lakini mzunguko ni chini kidogo kuliko kwenye kituo cha kazi. Tuliamua kuangalia athari za mzunguko wa kichakataji kwenye utendaji: hapakuwa na vichakataji vilivyo na masafa ya juu karibu kwa seva, kwa hivyo tulipunguza masafa ya kichakataji kwenye kituo cha kazi. Mara moja tuliipunguza hadi 1.6 ili uunganisho uwe wazi zaidi. Jaribio lilionyesha kuwa utendaji ulipungua sana, lakini hata kwa processor 1.6, kituo cha kazi kilitoa karibu vitengo 28, ambayo ni karibu mara 1.5 zaidi kuliko kwenye seva.
Kielelezo 4 - Vipimo vya utendaji kwenye kituo cha kazi na processor ya 1.6 Ghz
Kadi ya video
Kuna habari kwenye mtandao kwamba utendaji wa 1C unaweza kuathiriwa na kadi ya video. Tulijaribu kutumia video iliyojumuishwa ya kituo cha kazi, adapta ya kitaalamu ya Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, na kadi ya video ya zamani ya GeForce 16MbSDR. Wakati wa mtihani wa Gilev, hakuna tofauti kubwa iliyoonekana. Labda kadi ya video bado ina athari, lakini katika hali halisi, wakati unahitaji kufungua fomu zilizosimamiwa, nk.
Kwa sasa, kuna tuhuma mbili kwa nini kituo cha kazi hufanya kazi haraka hata na sifa mbaya zaidi:
- CPU. Aina ya processor kwenye kituo cha kazi inafaa zaidi kwa 1C.
- Chipset. Vitu vingine vyote vikiwa sawa, kituo chetu cha kazi kina chipset mpya zaidi, labda hili ndilo suala.
Tunapanga kununua vipengele muhimu na kuendelea na majaribio ili hatimaye kujua ni nini utendaji wa 1C unategemea kwa kiasi kikubwa. Wakati mchakato wa kuidhinisha na ununuzi unaendelea, tuliamua kufanya uboreshaji, hasa kwa vile haigharimu chochote. Hatua zifuatazo zilitambuliwa:
Hatua ya 1. Mpangilio wa mfumo
Kwanza, hebu tufanye mipangilio ifuatayo katika BIOS na mfumo wa uendeshaji:
- Katika BIOS ya seva, tunazima mipangilio yote ili kuokoa nguvu ya processor.
- Chagua mpango wa "Utendaji wa juu zaidi" katika mfumo wa uendeshaji.
- Kichakataji pia kimewekwa kwa utendaji wa juu. Hii inaweza kufanywa kwa kutumia matumizi ya PowerSchemeEd.
Hatua ya 2. Kuanzisha seva ya SQL na 1C:Seva ya Biashara
Tunafanya mabadiliko yafuatayo kwa DBMS na 1C:mipangilio ya seva ya Biashara.
- Kuweka itifaki ya Kumbukumbu iliyoshirikiwa:
- Kumbukumbu Inayoshirikiwa itawezeshwa tu kwenye jukwaa kuanzia 1C 8.2.17; kwenye matoleo ya awali, Named Pipe itawashwa - chini kidogo katika kasi ya uendeshaji. Teknolojia hii inafanya kazi tu ikiwa huduma za 1C na MSSQL zimesakinishwa kwenye seva halisi au pepe.
- Inashauriwa kubadili huduma ya 1C hadi hali ya utatuzi, kwani, kwa kushangaza, hii inatoa uboreshaji wa utendaji. Kwa chaguo-msingi, utatuzi umezimwa kwenye seva.
- Kuanzisha seva ya SQL:
- Tunahitaji seva tu, huduma zingine zinazohusiana nayo na, labda, mtu anazitumia, tu kupunguza kasi ya kazi. Tunasimamisha na kuzima huduma kama vile: Utafutaji wa Maandishi Kamili (1C ina utaratibu wake wa utafutaji wa maandishi kamili), Huduma za Ujumuishaji, n.k.
- Tunaweka kiwango cha juu cha kumbukumbu kilichotolewa kwa seva. Hii ni muhimu ili seva ya SQL ihesabu kiasi hiki na kufuta kumbukumbu mapema.
- Tunaweka idadi ya juu ya nyuzi (Upeo wa nyuzi za mfanyakazi) na kuweka kipaumbele cha seva kilichoongezeka (Kuongeza kipaumbele).
Hatua ya 3: Kuweka hifadhidata ya uzalishaji
Baada ya seva ya DBMS na 1C:Enterprise kuboreshwa, tunakwenda kwenye mipangilio ya hifadhidata. Ikiwa hifadhidata bado haijapanuliwa kutoka kwa faili ya .dt, na unajua takriban saizi yake, basi ni bora kuonyesha mara moja saizi ya uanzishaji kwa faili ya msingi na ">=" ya saizi ya hifadhidata, lakini hili ni suala. ya ladha, bado itakua wakati wa upanuzi. Lakini saizi ya kuongeza kiotomatiki lazima ibainishwe: takriban MB 200 kwa kila msingi na MB 50 kwa kila logi, kwa sababu Thamani chaguo-msingi - ukuaji kwa MB 1 na 10% kupunguza kasi ya kazi ya seva inapohitaji kuongeza faili kila muamala wa 3. Pia, ni bora kutaja uhifadhi wa faili ya hifadhidata na faili ya logi kwenye diski tofauti za mwili au vikundi vya RAID ikiwa safu ya RAID inatumiwa, na kupunguza ukuaji wa logi. Inashauriwa kuhamisha faili ya Tempdb kwa safu ya kasi ya juu, kwani DBMS huipata mara nyingi kabisa.
Hatua ya 4. Kuweka kazi zilizopangwa
Kazi zilizopangwa zimeundwa kwa urahisi kabisa kwa kutumia Mpango wa Matengenezo katika sehemu ya Usimamizi, kwa kutumia zana za picha, kwa hivyo hatutaelezea kwa undani jinsi hii inafanywa. Wacha tuangalie ni shughuli gani zinahitajika kufanywa ili kuboresha tija.
- Defragmentation ya indexes na uppdatering takwimu lazima kufanyika kila siku, kwa sababu ikiwa mgawanyiko wa faharasa ni > 25%, hupunguza sana utendaji wa seva.
- Takwimu za kutenganisha na kusasisha hufanywa haraka na hauhitaji kukata muunganisho wa watumiaji. Inashauriwa pia kuifanya kila siku.
- Re-indexing kamili - imefanywa na hifadhidata imefungwa, inashauriwa kuifanya angalau mara moja kwa wiki. Kwa kawaida, baada ya urekebishaji kamili, faharisi hutenganishwa mara moja na takwimu zinasasishwa.
Kama matokeo, kwa usaidizi wa kurekebisha mfumo, seva ya SQL na hifadhidata ya kufanya kazi, tuliweza kuongeza tija kwa 46%. Vipimo vilifanywa kwa kutumia zana ya 1C KIP na kwa kutumia jaribio la Gilev. Mwisho ulionyesha vitengo 25.6 dhidi ya 17.53 ambavyo vilikuwa hapo awali.
Hitimisho fupi
- Utendaji wa 1C hautegemei sana frequency ya RAM. Mara tu kiasi cha kutosha cha kumbukumbu kinafikiwa, upanuzi zaidi wa kumbukumbu hauna maana, kwani hauongoi kuongezeka kwa utendaji.
- Utendaji wa 1C hautegemei kadi ya video.
- Utendaji wa 1C hautegemei mfumo mdogo wa diski, mradi tu foleni ya kusoma au kuandika haipitiki. Ikiwa anatoa za SATA zimewekwa na foleni yao haijazidi, basi kufunga SSD haitaboresha utendaji.
- Utendaji unategemea sana mzunguko wa processor.
- Kwa usanidi sahihi wa mfumo wa uendeshaji na seva ya MSSQL, inawezekana kufikia ongezeko la utendaji wa 1C kwa 40-50% bila gharama yoyote ya nyenzo.
TAZAMA! Jambo muhimu sana! Vipimo vyote vilifanywa kwa msingi wa majaribio kwa kutumia jaribio la Gilev na zana za zana za 1C. Tabia ya hifadhidata halisi iliyo na watumiaji halisi inaweza kutofautiana na matokeo yaliyopatikana. Kwa mfano, katika hifadhidata ya majaribio hatukupata utegemezi wowote wa utendaji kwenye kadi ya video na kiasi cha RAM. Hitimisho hili linatia shaka kabisa na katika hali halisi mambo haya yanaweza kuwa na athari kubwa katika utendakazi. Wakati wa kufanya kazi na usanidi unaotumia fomu zilizosimamiwa, kadi ya video ni muhimu na processor yenye nguvu ya graphics huharakisha kazi katika suala la kuchora interface ya programu, kuibua hii inadhihirishwa katika kazi ya kasi ya 1C.
Je, 1C yako inafanya kazi polepole? Agiza matengenezo ya TEHAMA kwa kompyuta na seva na wataalamu wa EFSOL walio na uzoefu wa miaka mingi au uhamishe 1C yako hadi seva pepe ya 1C yenye nguvu na inayostahimili hitilafu.
Ujumuishaji wa mfumo. Ushauri
Kila mtu anayefanya kazi na bidhaa kwenye 1C:Enterprise jukwaa labda amesikia maneno "1C ni polepole." Watu wengine walilalamika juu yake, wengine walikubali malalamiko. Katika makala hii tutajaribu kuangalia sababu za kawaida za tatizo hili na chaguzi za kutatua.
Hebu tugeuke kwa mfano: kabla ya kujua kwa nini mtu hakuja mahali fulani, unapaswa kuhakikisha kuwa ana miguu ya kutembea. Kwa hiyo, hebu tuanze na mahitaji ya vifaa na mtandao.
Ikiwa Windows 7 imewekwa:
Ikiwa una Windows 8 au 10 iliyosakinishwa:
Pia kumbuka kwamba lazima iwe na angalau 2GB ya nafasi ya bure ya disk, na uunganisho wa mtandao lazima uwe na kasi ya angalau 100 MB / sec.
Haina maana sana kuzingatia sifa za seva katika toleo la mteja-server, kwa sababu katika kesi hii kila kitu kinategemea idadi ya watumiaji na maalum ya kazi ambazo hutatua katika 1C.
Wakati wa kuchagua usanidi wa seva, kumbuka yafuatayo:
- Mchakato mmoja wa mfanyakazi wa seva ya 1C hutumia wastani wa GB 4 (usichanganywe na muunganisho wa mtumiaji, kwani mchakato mmoja wa mfanyakazi unaweza kuwa na miunganisho mingi kama unavyobainisha katika mipangilio ya seva);
- Kutumia 1C na DBMS (haswa MS SQL) kwenye seva moja halisi hutoa faida wakati wa kuchakata kiasi kikubwa cha data (kwa mfano, kufunga mwezi, kuhesabu bajeti kulingana na mfano, nk), lakini hupunguza kwa kiasi kikubwa utendaji wakati wa shughuli zisizopakuliwa ( kwa mfano, kuunda na kufanya hati ya utekelezaji, nk);
- Kumbuka kwamba seva za 1C na DBMS lazima ziunganishwe juu ya kituo "nene" cha GB 1;
- Tumia diski za utendaji wa juu na usiunganishe majukumu ya seva ya 1C na DBMS na majukumu mengine (kwa mfano, faili, AD, mtawala wa kikoa, nk).
Ikiwa baada ya kuangalia vifaa 1C bado hupungua
Tuna kampuni ndogo, watu 7, na 1C ni polepole. Tuliwasiliana na wataalamu, na wakasema kuwa chaguo la seva ya mteja pekee ndilo litakalotuokoa. Lakini kwa ajili yetu ufumbuzi huo haukubaliki, ni ghali sana!
Fanya matengenezo ya kawaida katika hifadhidata*:
1. Fungua hifadhidata katika hali ya usanidi.
2. Chagua "Utawala" kwenye menyu kuu, na ndani yake - "Upimaji na urekebishaji".
3. Weka alama kwenye visanduku vyote kama kwenye picha. Bofya Run.
*Utaratibu huu unaweza kuchukua kutoka dakika 15 hadi saa moja kulingana na ukubwa wa hifadhidata na sifa za Kompyuta yako.
Ikiwa hii haisaidii, basi tunatengeneza unganisho la seva ya mteja, lakini bila uwekezaji wa ziada katika vifaa na programu:
1. Chagua kompyuta ya mezani iliyopakiwa angalau kwenye ofisi (sio daftari): lazima iwe na angalau GB 4 ya RAM na muunganisho wa mtandao wa angalau 100 MB/sec.
2. Washa IIS (Seva ya Habari ya Mtandao) juu yake. Kwa hii; kwa hili:
3. Chapisha hifadhidata yako kwenye kompyuta hii. Kuna nyenzo zinazopatikana kwenye mada hii kwenye ITS, au wasiliana na mtaalamu wa usaidizi.
4. Kwenye kompyuta za watumiaji, sanidi ufikiaji wa hifadhidata kupitia mteja mwembamba. Kwa hii; kwa hili:
Fungua dirisha la uzinduzi wa 1C.
Chagua msingi wako wa kazi. Hapa ni "Msingi Wako". Bofya "Hariri". Weka swichi kwa nafasi ya "Kwenye seva ya wavuti", onyesha kwenye mstari chini ya jina au anwani ya IP ya seva ambayo IIS iliamilishwa, na jina ambalo hifadhidata ilichapishwa. Bonyeza "Ijayo".
Weka "Njia ya Kuanzisha Msingi" kubadili kwenye hali ya "Mteja Mwembamba". Bofya "Imefanyika".
Tuna kampuni kubwa, lakini si kubwa sana, takriban watu 50-60. Tunatumia chaguo la seva ya mteja, lakini 1C ni ya polepole sana.
Katika kesi hii, inashauriwa kugawanya seva ya 1C na seva ya DBMS katika seva mbili tofauti. Wakati wa kutenganisha, hakikisha kukumbuka: ikiwa walibaki kwenye seva moja ya kimwili, ambayo ilikuwa tu virtualized, basi disks za seva hizi lazima ziwe tofauti - tofauti kimwili! Pia, hakikisha kuwa umeweka kazi za kawaida kwenye seva ya DBMS linapokuja suala la MS SQL (maelezo zaidi kuhusu hili yameelezwa kwenye tovuti ya ITS)
Tuna kampuni kubwa, zaidi ya watumiaji 100. Kila kitu kimeundwa kwa mujibu wa mapendekezo ya 1C kwa chaguo hili, lakini wakati wa usindikaji nyaraka fulani, 1C ni polepole sana, na wakati mwingine hitilafu ya kuzuia hutokea. Labda ufanye mpangilio wa msingi?
Hali kama hiyo inatokea kwa sababu ya saizi ya mkusanyiko maalum au rejista ya uhasibu (lakini mara nyingi zaidi - mkusanyiko), kwa sababu ya ukweli kwamba rejista "hufunga" kabisa, i.e. kuna harakati zinazoingia, lakini hakuna harakati za mtiririko, au idadi ya vipimo ambavyo mizani ya rejista huhesabiwa ni kubwa sana. Kunaweza kuwa na mchanganyiko wa sababu mbili zilizopita. Jinsi ya kuamua ni rejista gani inayoharibu kila kitu?
Tunarekodi wakati hati zinachakatwa polepole, au wakati na mtumiaji ambaye ana hitilafu ya kuzuia.
Fungua logi ya usajili.
Tunapata hati tunayohitaji, kwa wakati unaofaa, kwa mtumiaji sahihi na aina ya tukio "Data.Post".
Tunaangalia kizuizi kizima cha utekelezaji hadi shughuli itakapoghairiwa ikiwa kulikuwa na hitilafu ya kuzuia, au tunatafuta mabadiliko ya muda mrefu zaidi (muda kutoka kwa rekodi ya awali ni zaidi ya dakika).
Baada ya hayo, tunafanya uamuzi, tukikumbuka kwamba kuanguka kwa rejista hii kwa hali yoyote ni nafuu zaidi kuliko hifadhidata nzima.
Sisi ni kampuni kubwa sana, zaidi ya watumiaji 1000, maelfu ya hati kwa siku, idara yetu ya IT, kundi kubwa la seva, tumeboresha maswali mara kadhaa, lakini 1C ni polepole. Inaonekana tumezidi 1C, na tunahitaji kitu chenye nguvu zaidi.
Katika idadi kubwa ya matukio hayo, sio 1C ambayo inapungua, lakini usanifu wa ufumbuzi uliotumiwa. Wakati wa kuchagua mpango mpya wa biashara, kumbuka kuwa kuandika michakato ya biashara yako katika programu ni rahisi na rahisi kuliko kuibadilisha kuwa zingine, haswa mpango wa gharama kubwa sana. 1C pekee hutoa fursa hii. Kwa hivyo, ni bora kuuliza swali: "Jinsi ya kurekebisha hali hiyo? Unawezaje kufanya 1C "kuruka" kwa viwango kama hivyo? Wacha tuangalie kwa ufupi chaguzi kadhaa za matibabu:
- Tumia teknolojia za programu zinazolingana na zisizolingana ambazo 1C inaauni (kazi za usuli na hoja katika kitanzi).
- Wakati wa kubuni usanifu wa suluhisho, epuka kutumia rejista za mkusanyiko na rejista za uhasibu katika maeneo yenye vikwazo vingi.
- Wakati wa kuunda muundo wa data (mkusanyiko na/au rejista za habari), fuata sheria: "Jedwali la haraka zaidi la kuandika na kusoma ni jedwali iliyo na safu moja." Tunachozungumza kitakuwa wazi zaidi ikiwa utaangalia utaratibu wa kawaida wa RAUSE.
- Ili kuchakata idadi kubwa ya data, tumia nguzo za usaidizi ambapo hifadhidata hiyo hiyo imeunganishwa (lakini kwa hali yoyote hii haipaswi kufanywa wakati wa kazi ya mwingiliano !!!). Hii itakuruhusu kupitisha kufuli za kawaida za 1C, ambayo itafanya iwezekanavyo kufanya kazi na hifadhidata kwa karibu kasi sawa na wakati wa kufanya kazi moja kwa moja na zana za SQL.
Inafaa kumbuka kuwa uboreshaji wa 1C kwa wamiliki na kampuni kubwa ni mada ya nakala tofauti, kubwa, kwa hivyo endelea kutazama nyenzo zilizosasishwa kwenye wavuti yetu.
Dalili na historia ya mgonjwa:
Kazi ya watumiaji kadhaa kwenye mtandao na faili sawa (database) inajumuisha utaratibu wa kuzuia mtandao. Hii inalazimisha mfumo kupoteza muda muhimu kutambua vipindi vya wazi vya kurekodi na kutatua migogoro ipasavyo.
Dalili kuu za kuzuia operesheni:
- mtumiaji hufanya kazi haraka na hifadhidata kwenye mtandao katika hali ya kipekee na polepole sana wakati watumiaji kadhaa hufanya kazi kwa wakati mmoja
- uzoefu wa haraka wa mtumiaji na hifadhidata ya ndani kwenye seva na kufanya kazi polepole kwenye mtandao
- ufikiaji wa mfumo wa faili ni chini ya 10 MB/sec
Kwa hivyo, nilipewa jukumu la kuhakikisha kuwa watumiaji wengi kama watatu wanaweza kufanya kazi katika 1C kwa wakati mmoja! Mapenzi, sivyo?
Nilisahau utani wote nilipoona kile nilichopaswa kushughulika nacho: "seva" kwa namna ya kompyuta ya kawaida ya ofisi na kompyuta mbili za mkononi.
Furaha itakuwa haijakamilika ikiwa sio kwa mifumo ya ajabu ya uendeshaji - Windows 7 kwenye kompyuta na kwenye kompyuta moja ya mbali, Windows 8 kwa upande mwingine.
Wakati wa kujaribu kuchapisha hati kwa wakati mmoja kwenye kompyuta ndogo, moja ilikwama kwa takriban dakika moja, na ya pili ilianguka nje ya 1C na maandishi ya hitilafu "haikuweza kufunga meza ...".
Kuzindua 1C kwenye kompyuta ndogo ni onyesho tofauti ambalo lilidumu karibu dakika 3!
Kwenye rasilimali nyingi nilipata ushauri wa kubadili kufanya kazi katika ufikiaji wa wastaafu. Kwa bahati mbaya, Windows 7 haikuruhusu kugeuka kwenye seva ya terminal kwa kutumia zana za kawaida - kuna upeo wa uunganisho mmoja wa kazi. Katika kesi hii, vipindi vilivyobaki haviisha; unaweza kuunganisha tena chini ya mtumiaji mwingine - "kutupa nje" mtumiaji wa awali, lakini bila kusimamisha kikao chake. Kwa hiyo, unapaswa kuhamisha 1C kwenye OS ya seva, ambapo hakuna vikwazo vile. Mteja, kwa hatari yake mwenyewe, alitatua tatizo kwa kutumia shirika la tatu badala yake Windows7_SP1_RDPack.
Lakini adventures haikuishia hapo. Hata katika uunganisho wa terminal kulikuwa na ucheleweshaji mkubwa. Kwa mara nyingine tena injini za utafutaji za nguvu zote zilinisaidia kutoka. Chini ni vidokezo vya kuharakisha faili 1C, ambayo nilifuata:
1. Zima matumizi ya itifaki ya mtandao IPv6, sanidi anwani kwenye IPv4 ya "zamani".
2. Ongeza michakato ya 1C kwa vighairi vya ngome ya Windows, na vile vile vighairi vya antivirus, au uzime kabisa (hatari zaidi, lakini jaribio rahisi lilionyesha. kuongeza kasi uhamishaji wa hati wakati antivirus ya Avast imezimwa sababu ya!)
3. Anza kuorodhesha utafutaji wa maandishi kamili katika 1C au uizime kabisa
4. Endesha Upimaji na urekebishe hifadhidata, ukiangalia na matumizi ya ChDbfl
5. Endesha kipengee cha Angalia Usanidi katika usanidi (ikiwa usanidi sio kawaida, hii inaweza kuwa na manufaa). Kulingana na matokeo ya kuangalia usanidi, ilipungua kwa uchawi kwa karibu theluthi moja. Sikuchunguza haswa ni nini waandaaji wa programu zinazoingia walisasisha kabla yangu, lakini ukweli ni dhahiri.
6. Zima chaguo za kazi zisizohitajika.
7. Weka haki za mtumiaji. (Ushauri huu na wa hapo awali ulionekana kuwa wa kijinga hadi nilipoona utoaji wa fomu zinazodhibitiwa wakati wa kufungua orodha ya hati. Kadiri inavyokosa ulazima katika kiolesura kinachodhibitiwa, ndivyo inavyofanya kazi haraka, kama sheria)
8. Anza kuhesabu upya jumla na kurejesha mlolongo (ongezeko kubwa linaweza kutokea tu ikiwa jumla hazijarejeshwa kwa muda mrefu)
9. Taja "Kasi ya muunganisho - chini" katika mipangilio ya orodha ya hifadhidata (hii haikutoa matokeo mengi, isipokuwa kwamba picha za mfumo mdogo zilizimwa :))
Baada ya kukamilisha hatua hizi zote, hifadhidata ya faili ya 1C ilianza kufanya kazi haraka sana. Ilianza kuzinduliwa kwa upeo wa sekunde 10, na kasi ya uhamishaji wa hati iliongezeka kwa wastani mara 12.
Labda makala hii fupi itakuwa na manufaa kwako ikiwa ghafla unahitaji kuharakisha hifadhidata yako ya faili ya 1C.
P.S: Lakini kuzindua faili 1C kwa kutumia ufikiaji wa mtandao kwa folda iliyoshirikiwa bado sio kweli, kwa sababu ... Hata kiendeshi cha haraka sana cha hali dhabiti, RAM na kichakataji vitaingia kwenye vizuizi vya mtandao, na kazi ya zaidi ya mtumiaji mmoja itakuwa karibu haiwezekani. Tunazungumza mahsusi juu ya usanidi wa UT 11.1. Mipangilio ndogo iliyojiandika inaweza kufanya kazi haraka sana hata katika toleo la faili.
Nyongeza kutoka kwa maoni kwa uchapishaji:
Diski Defragmenter na msingi wa faili
Convolution hifadhidata (inaweza kuwa muhimu ikiwa hifadhidata ni kubwa, kwa mfano, kwa miaka kadhaa). Hifadhidata ya mteja ilikuwa changa sana, kwa hivyo kupunguzwa hakukuwa na maana.
Uboreshaji wa vifaa - gari ngumu haraka, swichi mpya, processor, nk.
Sakinisha kwenye seva ya wavuti, ufikiaji kwa kutumia mteja mwembamba. Hapa maoni yamegawanywa. Wengine wanasema ni mara nyingi haraka, wengine wanasema kuwa hakuna kuongeza kasi iliyobainishwa.
