Getting error "Operating system error in TnxMemoryStream: Espacio dealmacenamiento insuficiente para procesar este comando ($8/8) [$2B27/11047]"when doing a backup

Hello there,

I've seen in several customers' setups that our automated backup utility is returning this
error. Sometimes always. The error translated says something like: "Not enough available
storage space to process this command"

I just wonder where or why is this being generated, and how to workaround it (if possible).

In a particular case where I have the madExcept log I can see that there is around 1GB of
RAM available (of 3GB), but I don't have the amount of temporary storage (in the HDD)
right now (I'm working on getting it). I'm guessing the problem is that, but I am not sure.

The exception happens inside TnxBackupController.Backup.

I have configured the BatchSize to 2MB and the MAxTRansSizeMB to 128, I might try lowering
them and see if this solves the issue, but I would like to understand the cause.

Thanks in advance!

--
Rodrigo Gómez [NDX]
México, GMT-6

> I just wonder where or why is this being generated, and how to
> workaround it (if possible).

I'm not clairvoyant. Does it happen inside your clientside app? If so,
produce exception logs for it. Or is it server side? If so, get the
exception log from the customer.

--
Eivind Bakkestuen [NDD]

>
> I'm not clairvoyant. Does it happen inside your clientside app? If so,
> produce exception logs for it. Or is it server side? If so, get the
> exception log from the customer.
>

Sorry: the exception does happen on the client side. As for the server, there is no
indication of any exception in the exception log. I assume then that all of this is client
side.

The exception log on the client doesn't include a lot of usable info (I don't have debug
info enabled on the Nexus packages), but here is what I have:

exception class : EnxDatabaseError
exception message : Operating system error in TnxMemoryStream: Espacio de almacenamiento
insuficiente para procesar este comando ($8/8) [$2B27/11047].

thread $13d4 (TTareaRespaldo):
012042b6 +001a NexusDB412db240.bpl Nxdbbase Check
01234b64 +0398 NexusDB412db240.bpl Nxdbbackupcontroller TnxBackupController.Execute
01233769 +0061 NexusDB412db240.bpl Nxdbbackupcontroller TnxBackupController.Backup
0076f582 +1a1e TSUtilVariosC24.bpl RealizarRespaldo
009a6137 +33df TSBackups1Kernel.bpl TareaRespaldo.cpp 315 +293 TTareaRespaldo.DoExecute
0113421d +0025 NexusDB412ll240.bpl Nxllthread TnxThread.Execute
0077531a +0026 TSUtilVariosC24.bpl TTSThread Execute
5985ac8f +002b madExcept_.bpl madExcept HookedTThreadExecute
5985ab75 +000d madExcept_.bpl madExcept CallThreadProcSafe
5985abda +0032 madExcept_.bpl madExcept ThreadExceptFrame
74ceef1a +0010 kernel32.dll BaseThreadInitThunk
>> created by thread $27d4 (TManejadorTareas) at:
01134163 +002f NexusDB412ll240.bpl Nxllthread TnxThread.Create

I was hoping that maybe for the kind of error (and the class involved) you might be able
to pinpoint possible causes, even if not a definitive reason.

Anyway, I lowered the MaxTransSize to 32 and the BatchSize to 1 MB and at least in this
particular installation it worked.

As the madExcept report didn't scream of low memory I wasn't sure if that was the cause.
Here is what it reported regarding memory (and it actually includes the free disk space in
C, on both accounts I would expect to be enough:

physical memory : 1122/2935 MB (free/total)
free disk space : (C 231,60 GB
allocated memory : 72,10 MB
largest free block : 349,42 MB



--
Rodrigo Gómez [NDX]
México, GMT-6

Rodrigo Gomez [NDX] wrote:

> largest free block : 349,42 MB

This part here might be the problem. Your address space is fragmented. If you
aren't doing so, you might want to try out nxReplacementMemory manager to see
if that helps.

Otherwise, I would recommend to compile the client as 64bit to prevent this.

On 29/11/2017 12:18 a. m., Thorsten Engler [NDA] wrote:
> Rodrigo Gomez [NDX] wrote:
>
>> largest free block : 349,42 MB
>
> This part here might be the problem. Your address space is fragmented. If you
> aren't doing so, you might want to try out nxReplacementMemory manager to see
> if that helps.
>
> Otherwise, I would recommend to compile the client as 64bit to prevent this.
>

Uhm. C++Builder here, so I'm kind-of screwed in both ways.

Anyway, this small program might be a good candidate to try the port to 64bits.

Thanks for the help,

--
Rodrigo Gómez [NDX]
México, GMT-6