How do I track down crashes on the server?
This article has been machine translated. If you find any errors, we would be grateful if you could report them to translation@timesensor.com.
If you observe repeated crashes on your server, you must get to the bottom of the causes promptly. Every crash of a component of your server can impair the function of your database and, in the worst case, even damage your data.
General
A server is a complex system. There are numerous layers that can be described with the OSI model: low-level protocols work on the hardware (processors, memory, buses) and control the various components. On each abstraction level of the machine, there are again components that must rely on the functioning of the layer below. If the network card works incorrectly, the low-level protocol may be able to catch and correct certain errors and the machine will "only" become slow. However, certain errors cannot be corrected and packet losses occur. The layer on top of it again has its own strategy to deal with this situation, and so the system tries to keep itself dynamically in balance, with each layer having a certain, limited error tolerance.
Nevertheless, there are occasionally situations in which individual shifts get completely out of step and this leads to misbehaviour or even crashes on the machine. It is only in this situation that the end user notices that something is wrong with the machine.
Prevention
The best strategy is not to wait for such error situations, but to maintain the server preventively. Maintenance in this context means a regular analysis of the relevant log files on the different levels of the system. For example, timeSensor LEGAL keeps its own log files on the top level, the application layer, which concern the programme flow within timeSensor LEGAL. Below timeSensor LEGAL is the 4D database, which in turn keeps its own log files about the health and functioning of data storage in the database, about communication with client applications or about properties in the environment. Below this is the layer of the operating system, and the OS, be it Windows or macOS, also keeps a lot of log files about various activities, e.g. in the file system, about memory utilisation or the CPU. Server maintenance means that such log files of the different levels are regularly examined to get a picture of the "health" of the entire system.
Troubleshooting
Should crashes still occur, the troubleshooting phase begins. Users are often under the false impression that something is wrong with their application because this, e.g. timeSensor LEGAL, naturally represents the top layer of the system. Many errors, however, are located in the lower layers and are transmitted upwards, sometimes even to the application that runs in the application layer. Here is a checklist for systematic troubleshooting of crashes on your server:
1. Switch off Journal File
A "Journal File" can be set for the 4D database during data backup. This saves every transaction (adding, changing, deleting data records) in a file. The journal file is therefore in permanent and very intensive use. If there are problems at the file system level, writing to the journal file tends to go wrong, which can cause the database to crash. Therefore, first switch off the journal file and check whether this solves the crashes. If so, you should check your hard disk and replace it if necessary.
The journal file must always be located on the internal hard disk. Under no circumstances should you create the journal file on an externally connected disk or a network volume/NAS.
2. Switch off virus protection
Virus protection has no place on a database server. Since no one works on the database server, but the server is dedicated to the operation of the 4D database and timeSensor LEGAL, there is no risk of viruses on the server. No employee works on this computer, no e-mail programme is installed here and no one surfs the Internet on the database server. The virus protection programme slows down and hinders the good functioning of the database. It belongs on the workstations, but not on the database server. Only a minimal system may be installed on the database server so that interactions with the database can be excluded.
An anti-virus programme has no business on a database server.
3. Check storage space
Check whether at least 20% of the disk size is still free on all connected disks. For large data operations, cache files are created and then deleted again and for this the system needs air. Also check whether the database has enough memory. After the conversion from 32 to 64bit, there is a risk that the database does not use the available memory at all because the database settings are configured incorrectly. The database must be allocated enough memory so that it has enough air to work, but at the same time the OS must also have enough memory left. The more memory the database is allocated, the faster and more stable it will function, because it can then create a large cache in memory and the problem of memory fragmentation does not arise. If the database cannot use enough memory, the working memory can be fragmented to such an extent that certain operations can no longer be carried out and a crash is then the result.
Sufficient RAM and hard disk space are mandatory requirements for the good operation of the database.
4. Read and write rights
The database writes to a variety of files during operation: the journal file mentioned above (which hopefully you have turned off in the meantime), temporary files for cache operations, local preferences files, etc. If the operating system does not give the database this permission, it will not function reliably. Particularly dangerous is updating a macOS server from one operating system to another (major update). It has often been observed that after such an update, the access rights at OS level are no longer correct. As long as the operating system is still maintained by the manufacturer, i.e. security updates are still available, there is usually no reason to change the operating system on the server. No user will ever thank the manufacturer for this, because exactly which operating system is running on the server is completely irrelevant to the users. Never change a running system is the truism here. And should you nevertheless feel the urgent need to change the operating system of your server, then carry out a "Clean Install". The automatic update offered by Apple, for example, may be practical for a workstation, but it is the wrong procedure for a server.
Incorrect read/write permissions at the file system level are not uncommon and can cause the database to crash.
5. Clean Install
If all else fails, you should perform a clean install of the server: Back up the data, format the hard disk, install a new operating system and, as a last resort, replace the server.
A Clean Install solved almost all problems that were not due to the physical hardware.
Conclusion
Crashes on your server are not to be. Take them seriously, fix the causes and make sure your system is running properly to avoid damaging your database.
Related Articles
Client does not connect to the server
Initial situation When starting the tSL client, theError messagethat you should contact the administrator. Explanation This is because the client could not connect to the server. Solution You can restore the connection to the server by starting the ...How do support server access?
This article has been machine translated. If you find any errors, we would be grateful if you could report them totranslation@timesensor.com. General information Occasionally, it is necessary to allow employees of our support team to access the data ...App Nap and 4D Server
App Nap was released with Mac OS X 10.9 as an energy saver. Apps which are not in use will go to sleep. You should always disable App Nap on a Mac server that hosts the 4D server. You can disable App Nap for each application or for your entire ...How does the client find its server?
Background It may happen that the timeSensor Client no longer finds its server after an update, or that customers land on a test server on the same network when the productive server is turned off.This article discusses how 4D behaves in this regard. ...How do I test the connection to the server?
Background In order for you to work smoothly with timeSensor LEGAL, you need a fast and reliable Internet connection. If the server is on the same network as its workstation, i.e. in the local network (LAN), this is no problem. However, if the server ...