[RE]Re: Kallithea 0.7.0 Running Environment Questions

[김태호]

Hello Kallithea, Thank you so much.We ended up upgradingthe EC2 instane from t2.micro to r5.xlarge.So the specifications of the instance are as follows.(Intel Xeon3.1GHzSkylake-SP orCascade Lake) vCPU = 4, RAM = 32GiBWe set the thread value to 1 when you configure the ini file, the download will proceed as a result, although it is slow.The thing is the server would not be able to process anything else until the download is complete, so I want to increase the thread value more in the ini file.I'd like to know the possible risks.There is no other program running in the instance except for Kallithea.----- Original Message -----From : Mads Kiilerich <mads at kiilerich.com>To : "김태호" <taehokim at hicare.net>, <kallithea-general at sfconservancy.org>Cc : "박정환" <jeonghwan.park at hicare.net>Sent : 2021-06-17 06:07:21Subject : Re: Kallithea 0.7.0 Running Environment Questions
  
    
  
  
    On 6/15/21 1:02 PM, 김태호 wrote:
    
    
      
      
      
        We are testing by
            installing 0.7.0 version of Kallithea in two different
            environments.
        
        
        One was installed on
            WSL2 on my Windows 10 computer, and the other on EC2
            (t2.Micro, Ubuntu20.04) on AWS.
        The Kallithea git repo
            that I want to download is about 2.84GB.
        There was no problem when I installed it on my PC to verify
          that the installation process or configuration was wrong.
        
        
        
        If I run the Kallithea
            in WSL2, there is no problem with the download.
        
        
        The specifications of
            WSL2 are as follows.
        
        CPU : Intel(R) Core(TM)
            i7-1065G7 CPU @ 1.30GHz 1.50 GHz ( 8 core )
        RAM: 16 GB
        
        
        EC2 is (t2.Micro)
        vCPU:
            1
        RAM:
            1
        
        However, if I run on an
            EC2 instance, the following error :
        
        
        -->
            start
        
        
          error: RPC failed; HTTP
              417 curl 22 The requested URL returned error: 417
          
          fatal: the remote
              end hung up unexpectedly
        
        -->
            end
        
        
          
        Debug
            level log txt fileis attached.
      
    
    
    
    
    
    You saw this at the end of the log file:
    
    
    
    2021-06-15 10:31:38.805 DEBUG
      [kallithea.config.middleware.pygrack] handling cmd ['git',
      'upload-pack', '--stateless-rpc',
      '/var/kallithea/repos/Hicare-Smart/v2/hub-android']
      2021-06-15 10:33:12.303 ERROR
      [kallithea.config.middleware.pygrack] Traceback (most recent call
      last):
       File
"/home/ubuntu/kallithea/lib/python3.8/site-packages/kallithea/config/middleware/pygrack.py",
      line 160, in backend
       out = subprocessio.SubprocessIOChunker(
       File
"/home/ubuntu/kallithea/lib/python3.8/site-packages/kallithea/lib/vcs/subprocessio.py",
      line 365, in __init__
       raise EnvironmentError("Subprocess exited due to an error: %s"
      % err)
      OSError: Subprocess exited due to an error: b'error: pack-objects
      died of signal 9\nerror: git upload-pack: git-pack-objects died
      with error.\nfatal: git upload-pack: aborting due to possible
      repository corruption on the remote side.\n'
    
    
    
    Kallithea is invoking 'git', and Git fails, probably because the
      server is out of memory.
    
    
    You can perhaps reproduce pretty much the same problem by running
      this on the server:
     cd /var/kallithea/repos/Hicare-Smart/v2/hub-android
     git bundle create /tmp/bundle --all
    
    On the machine where the operation works on the same repo, you
      can try to use
     /usr/bin/time -v git bundle create /tmp/bundle --all
    and the line with "Maximum resident set size (kbytes)" will tell how
    much memory it is using.
    
    
    While it is hard to give any advice on server size, it seems
    reasonable that the the server at least must be of similar size as
    the repo, multiplied by some factor. Next, the server size will
    depend on for example how many simultaneous operations it should
    handle.
    
    
    I guess it would work (but be slow) if the system is configured
      with plenty of swap space. But real RAM is better.
    
    
    /Mads
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20210617/9dd3ca8e/attachment-0001.html>