The order of write operations must be maintained within a group. Therefore, these out of order requests must be stored in memory on the secondary host until the missing request comes in and completes.

The secondary host can store up to the hard-coded limit of 64 requests per group. Exceeding 64 stored requests stalls the primary host from issuing any more requests. This hard limit is applied only to the number of possible outstanding requests, not the size of their payload. For example, if the I/O consists of 4 Kbyte writes with six groups, the total memory requirement could be 4Kbyte x 6 x 64 = 1536 Kbyte. However, with an I/O size of 1 Mbyte, this requirement could rise to 1 Mbyte x 6 x 64 = 384 Mbyte. You need to be aware of this requirement to avoid exhausting the memory of the secondary host.

The most common symptom of secondary memory exhaustion is the volume sets changing to logging mode. The RPC requests fail when memory is low. To avoid the problem, change the number of asynchronous threads for some of the groups from the default of two to one. This forces the earlier version 3.1 behavior with no extra memory requirement on the secondary host.

The need for extra memory is most common with large I/O on a high latency link. When selecting groups to use a single thread, your best choices are those groups with a good network connection. Such groups are most likely to fill the secondary queue and they derive the least benefit from multiple threads.

Users upgrading from Sun StorEdge Availability Suite 3.1 software must be aware that the default number of asynchronous threads is two, not one. Out-of-order requests can occur and extra memory might be required on the secondary host.

Chapter 2 Remote Mirror Software Troubleshooting Tips 17

Page 26 Page 28
Page 27
Image 27
Sun Microsystems 3.2 manual Remote Mirror Software Troubleshooting Tips
Page 26 Page 28

3.2 specifications

Sun Microsystems 3.2, often referred to as SunOS 3.2, was a notable release of the Sun operating system that emerged during the rapidly evolving landscape of computer technology in the early 1980s. This operating platform was designed specifically for Sun Workstations, utilizing the robust hardware architecture developed by Sun Microsystems. The introduction of SunOS 3.2 marked a significant step forward in the development of UNIX-like operating systems optimized for entrepreneurship and scientific applications.

One of the main features of SunOS 3.2 was its adherence to the Berkeley Software Distribution (BSD) model, which allowed for advanced networking capabilities, enhanced performance, and efficient resource management. BSD's influence provided SunOS 3.2 with TCP/IP networking protocols, allowing users to connect to other devices seamlessly and manage network resources easily. This feature was crucial during a time when networking was becoming increasingly vital for organizations.

The system's support for virtual memory was another innovative characteristic. SunOS 3.2 utilized demand paging, which allowed programs to use more memory than was physically installed on their machines, significantly improving multitasking and overall system responsiveness. This capability was particularly advantageous for enterprises that relied on large-scale computations and data analysis.

SunOS 3.2 also introduced support for the Sun Window System, which meant users could utilize graphical user interfaces for interacting with applications, moving away from purely text-based command interfaces. This transition paved the way for more intuitive user experiences in the realm of computing, making powerful UNIX capabilities more accessible.

The inclusion of software utilities such as the C shell (csh) and a variety of development tools further strengthened SunOS 3.2’s position as a suitable platform for developers. The system provided robust development environments for programming in languages like C and assembly, catering to custom application requirements across different industries.

Lastly, security features were integrated into SunOS 3.2 to safeguard sensitive data and enhance system integrity. Permission settings and user authentication mechanisms were refined, allowing organizations to securely manage their computing resources.

In summary, SunOS 3.2 represented a landmark evolution in operating systems, showcasing a blend of advanced networking, memory management, graphical user interface, development tools, and security—elements that defined a generation of computing within the high-performance ecosystem of Sun Microsystems.
Top Page Image Contents