Working with UDXs and AEs

A classic, unfenced UDX runs inside a Netezza system process. Therefore, an unfenced UDX has access to the Netezza process memory address space. This implies that bugs that produce "wild pointers" can corrupt the Netezza system memory.

If separate process address space is necessary, use the UDX version called "fenced," which runs the UDX in a separate process. Fenced UDXs use the UDX API, which must be written in C or C++ and have a slower data transfer than unfenced UDXs since they are run in a different process.

AEs run in a separate process address space and do not have this memory corrupting potential. While AEs do not share memory with the Netezza system, they do use more system resources than unfenced UDXs.

A summary of the resources:
  • AEs are processes and not library code, such as an unfenced UDX. Processes inherently use more resources. For instance, a Linux installation encounters performance problems if there are too many simultaneous running processes. However, remote AEs might use fewer resources if the daemon style is used to service too many requests using threading. This is important for remote AEs where the Netezza system does not control their lifecycle so that unnecessary remote AEs are not left running in the background.
  • AEs and UDXs have access to local disk space on each SPU and the host. Using too much temporary disk space, especially on a SPU, can destabilize the Netezza system. Also, a high level of AE or UDX local disk I/O can compete with the Netezza system database I/O.
  • AEs and UDXs have access to the AE export directory tree. Because this is on a network drive, excessive use can impact the network performance of the entire Netezza system.

UDXs and AEs compete with the Netezza system for CPU, memory, network bandwidth, and disk I/O. The performance of the entire Netezza system can be impacted by UDXs or AEs if their combined resource usage becomes too high.

Some programming languages use more resources than others. For example, a script language interpreter, such as the one for Python, typically uses more system resources than the same functions implemented in C++.