Isso é exatamente o oposto da configuração de alta performance e provavelmente você vai querer seguir essas dicas se você quer diminuir o uso de memória pelo ASF, ao custo de diminuir o desempenho.

O ASF é extremamente leve em recursos, dependendo do uso até um VPS de 128MB com Linux é capaz de executá-lo, embora não seja recomendado usar uma configuração tão fraca que pode causar vários problemas. Mesmo sendo leve, o ASF pode pedir mais memória para o sistema operacional se ela for necessária para que o ASF opere com velocidade otimizada.

Como programa, o ASF tenta ser o mais otimizado e eficiente possível, o que também leva em conta os recursos usados durante a execução. Quando se trata de memória, o ASF prefere desempenho em vez de consumo de memória, o que pode acarretar "picos" temporários de memória que podem ser notados, por exemplo, em contas com mais de 3 páginas de insígnias, já que o ASF vai buscar e analisar a primeira página, ler dela o número total de páginas e então lançar uma tarefa de pedido para cada página extra, resultando na busca e análise simultânea das páginas restantes. O uso de memória "extra" (em comparação com o mínimo necessário para a operação) pode acelerar drasticamente a execução e o desempenho global ao custo de um aumento no uso da memória necessária para fazer todas essas coisas em paralelo. Algo semelhante acontece com todas as outras tarefas gerais do ASF que podem ser executadas em paralelo, por exemplo: a analise de ofertas de troca ativas, o ASF pode analisar todas elas ao mesmo tempo pois elas são independentes umas das outras. Além disso, o ASF (tempo de execução C#) não vai retornar a memória não utilizada de volta para o sistema operacional imediatamente, o que você pode notar rapidamente percebendo que o processo do ASF vai usando mais e mais memória sem (quase) nunca devolvê-la para o sistema operacional. Algumas pessoas podem achar isso questionável, até mesmo suspeitar de alguma falha na memória, mas não se preocupe, isso é esperado.

O ASF é muito bem otimizado e faz uso dos recursos disponíveis tanto quanto possível. Um alto consumo de memória pelo ASF não significa que ele ativamente usa essa memória e precisa dela. Muitas vezes o ASF vai manter memória alocada como "espaço" para ações futuras, pois nós podemos aumentar drasticamente o desempenho se não precisarmos pedir ao Sistema Operacional cada pedacinho de memória que venhamos a precisar. O tempo de execução deve liberar automaticamente a memória não utilizada pelo ASF de volta ao sistema operacional quando ele realmente precisar. Memória não utilizada é memória desperdiçada. Você terá problemas quando a memória necessária for maior que a memória disponível, e não quando o ASF mantiver alguma memória extra alocada com a intenção de acelerar funções que serão executadas em determinado momento. Você tem problemas quando seu kernel do Linux está matando o processo do ASF devido a OOM (falta de memória), não quando você vê o processo do ASF como o usuário principal da memória em htop.

Garbage collection process used in ASF is a very complex mechanism, smart enough to take into account not only ASF itself, but also your OS and other processes. Quando você tem um monte de memória livre, o ASF vai pedir o quanto for necessário para melhorar o desempenho. Isso pode chegar até a 1 GB (com o coletor de lixo de servidor). Quando a memória do sistema operacional estiver quase cheia o ASF automaticamente liberará uma quantidade de volta ao sistema operacional para ajudar a resolver isso, o que pode resultar na diminuição no uso geral de memória pelo ASF para até 50 MB. A diferença entre 50 MB e 1 GB é imensa, mas a diferença também é grande entre um VPS pequeno de 512 MB e um imenso servidor dedicado de 32 GB. Se o ASF puder garantir que essa memória será útil e nada mais precisa dela ao mesmo tempo, ele vai preferir mantê-la e se otimizar automaticamente baseado nas rotinas executadas anteriormente. O coletor de lixo usado no ASF se ajusta automaticamente e obterá melhores resultados quanto mais o processo for executado.

Também é por esse motivo que a memória utilizada no processo do ASF varia de um computador para outro, já que o ASF fará o seu melhor para utilizar os recursos disponíveis da melhor forma possível e não de uma forma fixa como era feito na época do Windows XP. O quantidade atual (real) de memória que o ASF está usando pode ser verificado com o comando status, e geralmente gira em torno de 4 MB para alguns bots ou até 30 MB se você usa coisas como o IPC e outros recursos avançados. Tenha em mente que memória retornada pelo comando stats inclui a memória livre que ainda não foi recuperada pelo coletor de lixo. O resto é memória compartilhada pelo tempo de execução (cerca de 40~50 MB) e o espaço para execução (podem variar). Também é por esse motivo que o mesmo ASF pode usar tão pouca memória quanto 50 MB em um ambiente VPS, enquanto usa até 1 GB em seu desktop. O ASF está ativamente se adaptando ao seu ambiente e tentará encontrar o equilíbrio ideal para não pressionar o seu sistema operacional nem limitar seu desempenho quando você tem um monte de memória não utilizada que pode ser colocado em uso.

Claro, existem muitas formas de apontar o ASF na direção certa em termos de quantidade de memória que pretende usar. No geral, se você não precisa disso, é melhor deixar o coletor de lixo trabalhar em paz e fazer o que ele achar melhor. Mas nem sempre isso é possível, por exemplo, se seu servidor Linux também está hospedando vários sites, bancos de dados MySQL e manipuladores PHP, então você realmente não pode permitir que o ASF diminua o uso de memória apenas quando você estiver perto de ficar sem ela, pois geralmente é tarde demais e leva a queda de desempenho. É normalmente nesse caso que você pode estar interessado em uma configuração mais detalhada e, portanto, em ler essa página.

As sugestões abaixo estão divididas em algumas categorias, com dificuldade variada.

As dicas abaixo não afetam negativamente o desempenho e podem ser aplicados com segurança a todas as configurações.

• Nunca execute mais de uma cópia do ASF. O ASF destina-se a lidar com um número ilimitado de bots de uma vez e a menos que você esteja vinculando cada cópia do ASF para diferentes interfaces/endereços de IP, você deve ter exatamente um processo do ASF, com vários bots (se necessário).
• Utilize o ShutdownOnFarmingFinished. Um bot ativo ocupa mais recursos que um desativado. Não é um ganho significativo, já que o estado do bot ainda precisa ser mantido, mas você está salvando uma certa quantidade de recursos, especialmente de todos os recursos relacionados à rede, tais como soquetes TCP. You can always bring up other bots if needed.
• Mantenha uma quantidade baixa de bots. Um bot sem o parâmetro Enabled toma menos recursos, já que o ASF não se preocupa em iniciá-lo. Também tenha em mente que o ASF tem que criar um bot para cada uma das suas configurações, portanto se você não precisa iniciar um bot com o comando start e quer salvar alguma memória extra, você pode renomear temporariamente Bot.json para, por exemplo, Bot.json.bak, para que o ASF não crie um bot inativo no processo. Desta forma você não será capaz de iniciá-lo pelo comando start sem renomeá-lo de volta, mas o ASF também não se preocupa em manter o estado deste bot na memória deixando espaço para outras coisas (é um ganho muito pequeno, em 99,9% casos você não deveria se preocupar com isso, só mantér seus bot com o parâmetro Enabled com o valor false).
• Fine-tune your configs. Especially global ASF config has many variables to adjust, for example by increasing LoginLimiterDelay you'll bring up your bots slower, which will allow already started instance to fetch badges in the meantime, as opposed to bringing up your bots faster, which will take more resources as more bots will do major work (such as parsing badges) at the same time. Quanto menos trabalho a ser feito ao mesmo tempo - menos memória é usada.

Essas são algumas coisas que você deve ter em mente ao lidar com o uso de memória. No entanto, essas coisas não têm qualquer papel "crucial" no uso de memória, porque o uso de memória vem principalmente de coisas com as quais o ASF tem de lidar e não de estruturas internas, utilizadas para a coleta.

As funções de recursos mais pesadas são:

• Análise da página de insígnias
• Análise do inventário

O que significa que a memória terá os maiores picos quando o ASF fizer a leitura das páginas de insignias, e quando ele está lidando com seu inventário (por exemplo, enviando trocas ou trabalhando com o STM). Isso acontece porque a ASF tem de lidar com uma enorme quantidade de dados - o uso de memória pelo seu navegador quando acessa essas duas páginas não será menor que isso. Desculpe, mas é assim que funciona - diminuir o número de páginas de insígnias e manter um número baixo de itens no seu inventário com certeza pode ajudar.

As dicas abaixo envolvem diminuição de performance e devem ser usados com cautela.

A maneira recomendada de aplicar estas configurações é por meio das propriedades de ambiente DOTNET_. Claro, você também pode usar outros métodos, p. ex.: runtimeconfig.json, mas é impossível definir algumas configurações desta maneira e, além disso, o ASF substituirá o seu arquivo personalizado runtimeconfig.json pelo arquivo próprio do ASF, portanto recomendamos propriedades de ambiente que você possa definir facilmente antes de iniciar o processo.

O tempo de execução do .NET permite que você ajuste o coletor de lixo de várias formas, melhorando-o efetivamente conforme as suas necessidades. Nós documentamos abaixo propriedades que são especialmente importantes em nossa opinião.

Specifies the allowable GC heap usage as a percentage of the total physical memory.

O limite de memória "difícil" para o processo do ASF, essa propriedade liga o Coletor de Lixo para usar apenas um subconjunto de memória total e não tudo. Isso pode se tornar especialmente útil em várias situações semelhantes a servidores, onde você pode dedicar uma porcentagem fixa da memória do seu servidor para o ASF, mas nunca mais do que isso. Esteja ciente que limitar a memória para uso do ASF não fará com que todas as atribuições de memória necessárias desapareçam magicamente, portanto, fixar este valor muito baixo pode resultar em situações de falta de memória, forçando a finalização do processo do ASF.

Por outro lado, definir esse valor alto o suficiente é uma maneira perfeita para garantir que o ASF nunca usará mais memória do que você pode realmente dispor, dando algum espaço para sua máquina respirar mesmo sob carga pesada, enquanto ainda permite que o programa faça seu trabalho eficientemente quando possível.

Specifies the amount of memory used after which GC becomes more aggressive.

This setting configures the memory threshold of your whole OS, which once passed, causes GC to become more aggressive and attempt to help the OS lower the memory load by running more intensive GC process and in result releasing more free memory back to the OS. É uma boa ideia definir essa propriedade para a quantidade máxima de memória (em porcentagem) que você considere "crítica" para o desempenho do SO. O padrão é 90% e vovê vai querer manter entre um intervalo de 80-97%, já que um valor muito baixo causará um agressão desnecessária do Coletor de Lixo e uma queda desnecessária de desempenho, enquanto um valor muito alto colocará uma carga desnecessária no seu SO, considerando que o ASF poderia liberar parte da memória para ajudar.

Especifica o nível de latência do coletor de lixo que você deseja otimizar.

Essa é uma propriedade não documentada que funciona excepcionalmente bem, limitando o tamanho das gerações de coleta de lixo e como resultado fazendo o coletor de lixo expurgá-los mais frequentemente e de forma mais agressiva. Default (balanced) latency level is 1, but you can use 0, which will tune for memory usage.

Quando ativo, nós ajustamos a memória alocada de forma mais agressiva para os segmentos de curta duração. Isso é usado para rodar vários processos no servidor, onde há a necessidade do menor uso de memória possível.

Isso oferece pouca melhoria, mas pode tornar o coletor de lixo ainda mais agressivo quando o sistema ficar com pouca memória, especialmente para o ASF que faz bastante uso de tarefas no pool de threads.

Você pode habilitar propriedades selecionadas ao definir variáveis de ambiente apropriadas. Por exemplo, no linux (shell):

# Don't forget to tune those if you're planning to make use of them
export DOTNET_GCHeapHardLimitPercent=0x4B # 75% as hex
export DOTNET_GCHighMemPercent=0x50 # 80% as hex

export DOTNET_GCLatencyLevel=0
export DOTNET_gcTrimCommitOnLowMemory=1

./ArchiSteamFarm # For OS-specific build
./ArchiSteamFarm.sh # For generic build

Ou no Windows (powershell):

# Don't forget to tune those if you're planning to make use of them
$Env:DOTNET_GCHeapHardLimitPercent=0x4B # 75% as hex
$Env:DOTNET_GCHighMemPercent=0x50 # 80% as hex

$Env:DOTNET_GCLatencyLevel=0
$Env:DOTNET_gcTrimCommitOnLowMemory=1

.\ArchiSteamFarm.exe # For OS-specific build
.\ArchiSteamFarm.cmd # For generic build

GCLatencyLevel será especialmente útil, pois verificamos que o tempo de execução de fato otimiza o código para a memória e portanto diminui significativamente o uso de memória, mesmo com o coletor de lixo do servidor. Esse é uma das melhores dicas que você pode aplicar se você deseja diminuir significativamente o uso de memória pelo ASF sem degradar demais o desempenho com OptimizationMode.

As dicas abaixo envolvem séria diminuição de performance e devem ser usados com cautela.

• Como um último recurso você pode ajustar o ASF para MinMemoryUsage (uso mínimo de memória) através do parâmetro de configuração global OptimizationMode. Leia atentamente a sua finalidade, pois se trata de uma queda muito grande de desempenho e resulta em pouquíssimos benefícios de memória. Normalmente essa é a última coisa que você quer fazer, depois de ter feitos os [ajustes do tempo de execução](#ajuste do-tempo-de-execução) para garantir que você está sendo forçado a fazer isso. Unless absolutely critical for your setup, we discourage using MinMemoryUsage, even in memory-constrained environments.

• Comece com as dicas simples de configuração do ASF, talvez você só esteja usando o ASF de forma errada, como iniciando o processo várias vezes para todos os bots, ou mantendo todos ativos quando você precisa iniciar automaticamente apenas um ou dois.
• If it's still not enough, enable all configuration properties listed above by setting appropriate DOTNET_ environment variables. Especialmente GCLatencyLevel, que oferece melhorias significativas de tempo de execução com pouca queda de desempenho.
• Se mesmo isso não ajudar, como um último recurso defina MinMemoryUsage em OptimizationMode. Isso força o ASF a executar quase tudo de forma síncrona, fazendo-o trabalhar muito mais devagar, mas também sem depender do pool de threads para equilibrar as coisas quando se trata de execução paralela.

É fisicamente impossível diminuir ainda mais o uso de memória, o ASF já estará com o desempenho seriamente afetado e você sem mais opções, tanto em termos de código quanto em termos de tempo de execução. Considere adicionar mais memória para o ASF usar, até 128MB faria uma grande diferença.