Server date Novell

Poate sa ma ajute cineva cu niste probleme aparute la un server de date Novell?
(Novell small business suite 6).

Adyp, on Apr 26 2005, 10:41, said:

Incerc, daca dai detaliile :-)

Statiile  de lucru win95 si win98 cu client 3.1. , am aproape 40 de calc. in retea.
Ce se intampla: am o statie logata la server totul este ok restartez statia de lucru iar cand sa o loghez iarasi imi spune ca nu ma pot loga cu acelas user de mai multe ori in acelas timp. Am observat ca vechea conexiune ramane activa pe server o anumita perioda iar daca nu las sa treaca aceasta perioda nu ma pot loga cu userul ala. Aceasta perioda e in jur de 1 min. Asta mi se intampla de cand am schimbat placa de retea de pe server si am pus o placa de 1000 .
Am cautat peste tot sa gasesc o setare dar nu am gasit.
Asta ar fi una din probleme sper ca am fost destul de explicit si iti multumesc daca ma poti ajuta .
Gasesti putine persone si greu care sa aiba habar de novell.

Adyp, on Apr 27 2005, 09:02, said:

Problema este la driverul placii de retea noi din server sau lipsa unui patch / Service Pack la NSBS 6.
Cum stai la patch-uri si SP-uri?
Ce fel de placa este cea de 1000 si ce driver foloseste?
Nume driver, dimensiune, data, versiune?
Ai citit eventualul README.TXT de pe discheta/CD-ul placii de retea?


In continuare detalii explicative:

1. De ce 1 minut:

If the user powers off without logging out, the client connection remains open and the user cannot to log in again until the connection is cleared. The server's watchdog process retries the connection a designated number of times, and then the connection times out and the server clears the connection. After the connection is cleared, the user can log in again.

Watchdog processes are controlled by Watchdog (Communications category) SET parameters.

NU modifica aceste setari deocamdata!


2. Salvare parametrii SET in fisier:

To write current values of settable parameters to a file and print it, complete the
following:

Access NetWare Remote Manger.
Click the Set Parameters link in the navigation frame.
In the Save Settings to a File on Volume SYS: field, accept the default filename

(SETTINGS.TXT) or enter a different filename.
Click the Save button to the right of the Save Settings to a File on Volume SYS: field.

Ataseaza eventual fisierul.


3. Cum vezi cind e stearsa conexiunea unei statii:

To do this, SET CONSOLE DISPLAY WATCHDOG LOGOUTS = ON at the server to see if watchdog was clearing the connection. You will receive the following error on the server console regarding a user on the server if watchdog is clearing the connection.

SERVER-410-745: User <login name > on station <connection number > cleared by connection watchdog. Connection cleared due to communication or station failure.


4. Detalii complete despre procesul watchdog:
http://developer.nov...une/b010601.htm

Am atasat driverul placii pe care o folosesc.
Inainte de a folosii aceasta placa am folosit una de 100.
Patch-uri si SP-uri nu am pus pe server.
Linck-ul ce lai pus e foarte bun si setarile mele de pe server par bune.
Cu setarile pe care le am acum dar cu placa de 100 nu pateam asa ceva.
Tot de cand am pus placa de 1000 cand copiez de pe calc pe server procentul de utilizare din Monitor de pe server creste foarte mult, uneori si pana la 80% ajung varfuri si nu prea e constanta aceasta valoare fata de momentul cand foloseam placa de 100.

Ai verificat ca cele 2 fisiere suport NLM (ETHERSTM.NLM si MSM.NLM) de pe discheta au ajuns si ele pe server in timpul instalarii?
Pe server ar trebui sa fie acum cele de pe discheta cu driver sau eventual versiuni mai noi.
Probabil dadea erori daca nu erau bune, dar oricum verifica.

Partea cu CPU la +80% poate fi normala. Placa mai rapida "trage" mai tare de procesor. Ai constatat cumva ca placa noua NU transfera datele la viteza asteptata?

Completare:
Am gasit un driver mai nou pe site-ul Realtek. Este atasat, incearca si cu acest driver, dar numai dupa ce te-ai convins ca cele 2 fisiere NLM suport de pe server sunt potrivite.

Edited by klaszlo, 30 April 2005 - 16:01.

Cele 2 fisiere exista si driverul sa instalat perfect fara probleme nu am incercat inca driverul nou dar o sa-l incerc.
Treaba cu 80% nu e bine sa creasca asa mult acest procent fiindca e indicat sa se mentina la o valoare mai scazuta si cat de cat constanta iar la mine numai constanta nu e are variatii destul de mari adica 20% , 70%, 30%, 80% si tot asa in conditiile in care de exemplu eu copiez un fisier mare compact, nu pot sa zici ca sunt multe fisiere si marunte in directorul pe care il copiez si de aia variaza asa procentul.
La mine mai este o chestie serverul nu lucreaza cu cache si nici statiile de lucru fiindca programele de retea (contab. si altele) sunt facute in Foxpro 2.6 care nu prea este compatibil cu Novellul si din aceasta cauza am avut probleme.
Rezolvarea a fost, o parte a problemei, dezactivarea cache-lui de pe server si de pe statii.
Sa influenteze si chestia cu cache-ul procentul?

Adyp, on May 3 2005, 09:19, said:

OK, astept concluzia.

Adyp, on May 3 2005, 09:19, said:

Dar fenomenul a aparut doar de cind ai trecut la placa de gigabit, deci e legata de modul in care lucreaza driverul acestei placi si de faptul ca procesorul a ramas la aceeasi viteza, cu aceeasi memorie RAM.
Functionarea interna a serverului e mult mai complicata, poate gasesc un link cu detalii, ca sa intelegi ce se intimpla.

Adyp, on May 3 2005, 09:19, said:

Ce ai dezactivat pe server si pe statii?
Care parametru SET, respectiv care setare din configurarea clientului?
Intreb fiindca facilitatea de opportunistic locking care putea sa deranjeze eventual Foxpro este dezactivata by default la instalare (sau cel putin asa stiu eu).
Dealtfel cred ca aplicatiile scrise in Foxpro le-ai folosit si cu placa veche si cache-uri dezactivate, atunci cum de functiona "lin" serverul?

Programele facute in Fox lucreaza la fel si dupa schimbarea placii si setarile astea le-am avut si pana sa schimb placa, am vrut sa stii ca am facute setarile acestea cu cache-ul gandinduma ca au vreo influenta asupra placii noi.
Ce setari am facut:
  Cache writes = off
  File cache level = 0
  True commit = on
Astea sunt facute pe statii.
Setarile astea sunt recomandate impreuna cu un patch pentru rezolvarea problemelor  cauzate de foxpro 2.6. (recomandate pe novell.com) si rezolva intro oarecare masura problemele cu fox-ul.


Pe server in Communication

Number Of Watchdog Packets                           10  
Delay Between Watchdog Packets                     59.3 seconds  
Delay Before First Watchdog Packet                  4 minutes 56.6 seconds  
Console Display Watchdog Logouts                   ON  
Maximum Packet Receive Buffers                     10000  
Minimum Packet Receive Buffers                      2000  
Maximum Physical Receive Packet Size             4224  
New Packet Receive Buffer Wait Time               0.1 seconds  
Maximum Interrupt Events                              30  


Traditional File System    

Minimum File Cache Buffers                            20
Maximum Concurrent Disk Cache Writes          4000  
Dirty Disk Cache Delay Time                          0.1 seconds

Scuze daca acest post a iesit prea lung, dar am vrut sa intelegi exact ce se intimpla.

Adyp, on May 3 2005, 13:45, said:

Primele 2 setari de pe client rezolva intr-adevar problema veche a aplicatiilor xBase folosite in retea (vezi aici un articol non-Novell din 1999 http://home.earthlin...cs/clipper1.htm.)

Ma mir in schimb de a 3-a setare care nu are de a face cu aceasta problema, dar in schimb "desfiinteaza" complet avantajele file cache-ului de pe server, care nu are nici o vina deobicei.
Novell il recomanda doar ca solutie sigura pentru a evita coruperea datelor (doar in anumite situatii), vezi detaliile de la sfirsit.

Influenta asupra placii de retea noi e cam asa:
- serverul (nefolosind file cache-ul din RAM pt. accesele la fisierele de pe server din cauza lui True commit = on de pe statii) utilizeaza mult timp procesor pentru a accesa  harddiscul. Sa nu uitam ca file cache-ul din serverul Netware este optimizat pentru mediu multiuser (cind True commit = off, setarea implicita).
- placa veche din server era mai lenta si trimitea pachetele cu o rata acceptabila serverului Netware, care se descurca cu ele, chiar si cu file cache-ul inhibat.
- placa noua in schimb "bombardeaza" serverul cu pachete la o rata mai mare, iar acesta apeleaza din greu la CPU pt. a accesa harddiscul.

Mai pe romaneste, serverul a mers si pina acum intr-un mod "degradat", dar numai acum simti asta.

Daca mai ai referinta Novell in care recomandau "True commit = on", te rog s-o postezi, sunt curios in ce context au facut-o.

Astept rezultatele cu driverul nou.


Detalii:
Articole Novell TID (doar 2 si 3 recomanda True commit = ON.)

1.
Technical Information Document
FoxPro index rebuild corrupted - TID2950761 (last modified 19MAY1999)

symptoms
  
When rebuilding indexes on the tables in a Visual FoxPro 5 database, it seems like the
FoxPro files are becoming corrupted.
Problem happens on a Windows 95 workstaiton with the 3.1 client. FoxPro database is

running on a NetWare 4.11 server with the latest patches.

solutions
  
Turn off "cache writes" in the advanced settings of the client. By default, "cache
writes" is turned "on" when the client is installed. File Cache level was also set to
'0". Both of these settings decrease the performance of the connection to the server but
allowed the customer to rebuild the database without errors. These settings are provided
to give maximum compatability with some applications, and maximum performance to those
who do not have compatability problems with their applications. Generally, only older
applications have compatability problems with the higher-performance settings.

***********************
2.
Technical Information Document
File Locking w/Nw5 clients - TID2951559 (last modified 13FEB2000)

symptoms
  
Several users had complained about sharing violations with files they were using. This
has happened on several applications (Excel, Access, Foxpro DB programs and even regular
text files using the copy command). They were having to reboot the machine before the
client would let go of the file. After putting End of Job to ON they only had to close
out of the application, but it was still a problem.
solutions
  
We were unable to reproduce these problems at Novell.

These 5 settings fixed the problem only after they reinstalled the clients:
Delay Write =OFF
End Of Job =ON
Cache Writes = OFF
Hold Files = ON
True Commit = ON

Normally we do not suggest setting True Commit = ON due to the large performance hit that
this takes on file access both on the server and from the workstation

***********************
3.
Technical Information Document
File Locking with NetWare 5 clients - TID10027140 (last modified 09OCT2002)

fact
Novell NetWare Client for Windows 95/98
Novell NetWare Clients for Windows NT
Microsoft Windows 95/98
Microsoft Windows NT  Workstation 4.0

symptom
  
File Locking with NetWare 5 clients

Error:  sharing violations on several applications: Excel, Access, Foxpro DB programs,
Lotus organizer.
User has to reboot the machine to release file locks.

fix
  
These 5 settings fixed the problem only after they reinstalled the clients:

Delay Write =OFF
End Of Job =ON
Cache Writes = OFF
Hold Files = ON
True Commit = ON

or,

Sometimes,  just putting End of Job on solves the problem.
Normally we do not suggest setting True Commit = ON due to the large performance hit that
this takes on file access both on the server and from the workstation.
****************

4.
Setarile modificate explicate, in TID 10013620:

Cache Writes
     Registry Key: HKLM\Network\Novell\System Config\NetWare DOS Requester\CACHE WRITES
     Registry Value: [string] 0
     Default Value: YES (ON)
     Range: YES, NO (GUI shows this as ON, OFF, registry uses YES, NO)
     Client Version: Implemented by at least the 95/98 Client version 2.5 or higher.
     Description: Improves performance for writing files to the network by allowing the client to save changes to workstation memory before saving them to the network. If this is disabled, then the Novell Client must submit the file write changes to the server before being allowed to continue on (will create a longer delay in the time applications pause during a file write). This is not the same as the True Commit parameter which goes a step further and requires that the server acknowledge that the file changes have actually been committed to the volume on the server (not just submitted to be written) before being allowed to continue on.

File Cache Level
     Registry Key: HKLM\Network\Novell\System Config\NetWare DOS Requester\FILE CACHE LEVEL
     Registry Value: [string] 0
     Default Value: 3
     Range: 0 - 3
     Client Version: Implemented by at least the 95/98 Client version 2.5 or higher.
     Description: Specifies the type of file caching used at the client. The larger the value, the more aggressive the client will be in caching files and the better the performance. Some applications may be intolerant of aggressive file caching and may require this setting to be disabled (0).

True Commit
     Registry Key: HKLM\Network\Novell\System Config\NetWare DOS Requester\TRUE COMMIT
     Registry Value: [string] 0
     Default Value: NO (OFF)
     Range: YES, NO (GUI shows this as ON, OFF, registry uses YES, NO)
     Client Version: Implemented by at least the 95/98 Client version 2.5 or higher.
     Description: This controls whether buffers flushed by an application are commited immediately to disk on the server. Setting this value to On will ensure data integrity at the expense of significantly reduced file write performance. This is because the when this is set On, the Client must immediately commit the file changes to disk on the server and must wait until the server acknowledges that the changes have been written instead of just requiring an acknowledgement from the server that the write request has been received (shows as disk request and then as dirty cache buffer if it sits long enough). This parameter is an implementation of the File Commit functionality used in the Windows NT Novell Client.

Edited by klaszlo, 04 May 2005 - 08:35.

Cu driverul nou nu e nici o schimbare, se manifesta la fel.

Nu mai reusesc sa dau de link-ul ala dar sa sti ca ai dreptate cu true commit=on.
Pana la urma problema e placa de retea care face un trafic uneori peste putintele si resursele procesorului.
Procesorul e de 1600 cu 512 ram cu hard de 7200 rotatii cam putin nu la 35 de pc cate am in retea.
Sa pun un procesor mai mare sau sa mai pun ram sau ambele.

Adyp, on May 5 2005, 09:20, said:

Se pare ca totusi va trebui sa aplici acel SP de 300 MB pina la urma, fiindca nu gasesc ceva dedicat pt. problema asta cu "watchdog-ul aiurit", sorry.
Dar numai daca chiar crezi ca merita efortul. Aici e linkul pt. Netware 6.0:
http://support.novel...gi?/2969166.htm

Adyp, on May 5 2005, 09:20, said:

Si atunci renunti la aceasta setare? Poate numai pe una sau citeva statii, pentru teste?
Intreb fiindca atunci (daca poti renunta pe toate statiile) vei avea un server "nou", care se va comporta cu totul altfel, adica va reveni la normal.

Adyp, on May 5 2005, 09:20, said:

Bingo :-)

Adyp, on May 5 2005, 09:20, said:

Aici te ajuta Monitorul cu acele contoare minunate...
Pentru memorie verifica Total cache buffers si imparte-l la Original cache buffers.
Se gasesc pe pagina General Information in Monitor.
O regula straveche spune ca daca este sub 40% se va adauga memorie.
Cu 512 Mb m-as mira sa fie asa.

O alta regula spune ca LRU Sitting Time sa nu fie sub 15 minute.
Daca este se va adauga memorie.
Dar aceasta regula presupune ca functioneaza normal file cache-ul pe server, ceea ce la tine nu se intimpla.

Upgrade-ul de procesor este oricum binevenit, dar depinde si de ce hotarasti cu True commit.
S-ar putea sa nu mai fie nevoie de upgrade...
Sau sa inceapa sa-ti corupa datele. Putin probabil totusi, mai ales daca nu ai avut aceasta problema la inceput, adica inainte de a modifica setarile de pe clienti.

S-ar mai putea modifica o mie de setari pe server, dar depinde de ce vrei sa faci cu SP-ul, cu True commit, etc.

O sa renunt pe toate statiile la true coomit asta in primul rand sa vad ce se intampla.
Si cu placa de 100 am avut baze de date corupte si acuma cu placa asta am destul de rare dar am.
Sa vad odata ce se intampla cu true commit dar eu cred ca procesorul trebuie marit sau sa vin cu un hard mai rapid.
Memorie eu zic ca e suficienta.
Eu zic ca problema e cu nr de cereri pe care le poate rezolva serverul intro anumita perioda de timp.
Acel SP de care zici tu e sigur nu imi da serverul peste cap, lai incercat?

"O alta regula spune ca LRU Sitting Time sa nu fie sub 15 minute."
Nu inteleg cum vine asta sa fie sub 15 min.
LRU nu iti arata cat timp a fost serverul in functiune neintrerup?
Mersi mult mai ajutat foarte mult pana acum.

Adyp, on May 5 2005, 13:46, said:

:-)
LRU Sitting Time arata eficienta file cache-ului, vezi detalii mai jos.

Adyp, on May 5 2005, 13:46, said:

Cu placere.

Detalii privind LRU:
"LRU Sitting Time

NetWare's file caching subsystem is a pool or collection of 4 KB memory pages. After loading the OS, system NLMs, and application NLMs, NetWare initializes all remaining memory as the file cache pool. At the beginning of the list is the "list head," where new cache buffers are inserted into the list. The end of the list is the "list tail," where old cache buffers are removed from the list. Each cache buffer in the list is linked to the next cache buffer, and each one includes a time stamp indicating the time the cache buffer was inserted into the list head.

When the server receives a disk I/O request for data that is not currently in cache (a cache "miss"), the data is read from the disk and written into one or more cache buffers that are removed from the list tail. Each newly filled cache buffer is time-stamped with the current time and linked into the list head. A newly filled cache buffer is designated as the most-recently-used (MRU) cache buffer because it has resided in cache for the least amount of time.

A cache "hit" a frequent event in NetWare environments  occurs when a disk request received by the server can be serviced directly out of cache, rather than from disk. In this case, after the request is serviced the cache buffer containing the requested data is removed from the list, time-stamped with the current time, and relinked into the list head. In this manner, MRU cache buffers congregate at the head of the list. This characteristic of the list is important to understand, because you want your MRU cache buffers to remain cached in anticipation of repeated use and repeated cache hits.

At some point in this process, the file cache pool becomes full of recently used data. This is where the least-recently-used (LRU) cache buffer comes into play. LRU cache buffers are buffers that were originally filled from the disk, but haven't been reused as frequently as the MRU cache buffers at the list head. Due to the relinking of MRU cache buffers into the list head, LRU cache buffers congregate at the list tail. When new cache buffers are needed for data requested from disk, NetWare removes the necessary number of LRU cache buffers from the list tail, fills them with newly requested data, time-stamps them with the current time, and relinks them into the list head.

The resulting NetWare file cache subsystem gives preference to repeatedly used data and holds onto less frequently used data only as long as the memory isn't needed for repeatedly used data.

When tuning file cache, then, the ideal scenario is one in which every repeated use of recently accessed data can be serviced out of cache. This is accomplished by sizing server memory so that the resulting file cache pool is large enough to retain all repeatedly used data.

The LRU Sitting Time statistic is calculated by taking the difference between the current time and the time stamp of the LRU cache block at the tail of the cache list. LRU Sitting Time measures the length of time it is taking for an MRU cache buffer at the list head to make its way down to the list tail, where it becomes the LRU cache buffer. One might refer to this measurement as the cache "churn rate" because, whether from cache hits or misses, every cache buffer in the list is being reused within that period of time. Check that the LRU Sitting Time does not go below 15 minutes. If it drops below 15 min, you may need to add more memory."

Banuiesc ca faci backup la datele alea zilnic.
Iar structura NDS (useri, grupuri, volume, drepturi, etc) sunt bine documentate.

Sa faci doar o schimbare deodata, apoi stai si trage concluzii.
Cam asta ar fi ordinea:
1. Revenit cu true commit pe statii.
2. Vazut cum merge serverul citeva zile de lucru: LRU a coborit sub 15 minute?, CPU cum sta?, cache buffer sunt destule?, se mai corup datele foarte des?, etc
3. Daca e cazul: update procesor, reluat pasul 2.
4. Daca e cazul: add memory, reluat pasul 2.
5. Aplicare SP, reluat pasul 2 si verificat daca problema cu watchdog-ul a disparut. Nu pot garanta asta 100 %.

Referitor la SP-ul de 300 MB, nu l-am instalat pe un 6.0 inca.
Pe 5 era ca si cum ai fi reinstalat totul, in sensul ca putine fisiere au ramas neschimbate, durata a fost mare, dar nu au fost probleme de functionalitate in final.
Insa au crescut cu citeva procente incarcarea procesorului si consumul de memorie.
Daca nu ai experienta unei asemenea operatii iti recomand sa faci o proba pe un alt calculator inainte.
Am intilnit o singura data situatia in care din cauza de fisier corupt pe CD (sau a unitatii de CD), update-ul s-a oprit pe la mijloc, iar serverul a ramas neoperational, a trebuit reinstalat de la zero...
Deci ai backup-uri si documentatie?!
Succes!

De luni o sa incep schimbarile pe rand.
Se poate instala serverul fara a afecta partitia de date HOME?
E in regula si cu memoria ajunge cata e poate la procesor o sa trebuiasca umblat.

Adyp, on May 6 2005, 13:42, said:

Spor.
Da, se poate.