การแพ็คที่เก็บ Git ใหม่ล้มเหลว

ฉันมีที่เก็บ git อยู่บนเซิร์ฟเวอร์ที่มีหน่วยความจำจำกัด เมื่อฉันพยายามโคลนพื้นที่เก็บข้อมูลที่มีอยู่จากเซิร์ฟเวอร์ ฉันได้รับข้อผิดพลาดต่อไปนี้

hemi@ubuntu:$ git clone ssh://[email protected]/home/hemi/repos/articles
Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/
[email protected]'s password: 
remote: Counting objects: 666, done.
remote: warning: suboptimal pack - out of memory
remote: fatal: Out of memory, malloc failed
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
hemi@ubuntu:$

เพื่อจัดการกับข้อผิดพลาดนี้ ฉันได้พยายามที่จะบรรจุพื้นที่เก็บข้อมูลเดิมใหม่ (ตาม โพสต์ในฟอรัมนี้) แต่แทนที่จะบรรจุพื้นที่เก็บข้อมูลใหม่ กลับอธิบายวิธีใช้คำสั่ง "git pack-objects"

hemi@servername:~/repos/articles$ git repack -a -d --window-memory 10m --max-pack-size 100m
usage: git pack-objects [{ -q | --progress | --all-progress }]
        [--all-progress-implied]
        [--max-pack-size=N] [--local] [--incremental]
        [--window=N] [--window-memory=N] [--depth=N]
        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*]
        [--reflog] [--stdout | base-name] [--include-tag]
        [--keep-unreachable | --unpack-unreachable 
        [<ref-list | <object-list]

มีการติดตั้ง Git 1.6.5.7 บนเซิร์ฟเวอร์


git repository
person midtiby    schedule 28.01.2011    source แหล่งที่มา

คำตอบ (7)


arrow_upward
116
arrow_downward

โซลูชันของคุณช่วยให้คุณได้รับสำเนาที่ใช้งานได้ทั้งในเครื่องและจากระยะไกล แต่จะทำให้เกิดปัญหาอีกครั้งเมื่อพื้นที่เก็บข้อมูลระยะไกลตัดสินใจแพ็กตัวเองใหม่อีกครั้ง โชคดีที่คุณสามารถตั้งค่าตัวเลือกการกำหนดค่าที่จะลดจำนวนหน่วยความจำที่จำเป็นสำหรับการบรรจุใหม่ในที่เก็บข้อมูลทั้งสองแห่ง สิ่งเหล่านี้จะทำให้พารามิเตอร์บรรทัดคำสั่งที่คุณเพิ่มลงในตัวเลือกเริ่มต้นเมื่อทำการบรรจุภัณฑ์ใหม่ ดังนั้น คุณควรเข้าสู่ระบบระยะไกล เปลี่ยนเข้าไปในพื้นที่เก็บข้อมูล และทำ:

git config pack.windowMemory 10m
git config pack.packSizeLimit 20m

คุณอาจต้องการทำเช่นเดียวกันกับพื้นที่เก็บข้อมูลในเครื่องของคุณ (บังเอิญฉันเดาว่าที่เก็บของคุณมีขนาดใหญ่มากหรือเป็นเครื่องที่มีหน่วยความจำน้อย - ค่าเหล่านี้ดูเหมือนต่ำมากสำหรับฉัน)

สำหรับสิ่งที่คุ้มค่า เมื่อได้รับความล้มเหลวของ malloc ในการบรรจุที่เก็บข้อมูลขนาดใหญ่ มาก ในอดีต ฉันยังได้เปลี่ยนค่าของ core.packedgitwindowsize, core.packedgitlimit, core.deltacachesize, pack.deltacachesize, pack.window และ pack.threads แต่ฟังดูเหมือนคุณ ไม่ต้องการตัวเลือกเพิ่มเติมใด ๆ :)

person Mark Longair    schedule 28.01.2011
comment
ขอบคุณสำหรับตัวเลือกการกำหนดค่า ฉันไม่ทราบมาก่อน พื้นที่เก็บข้อมูลประกอบด้วยไฟล์ PDF ชุดใหญ่ ขนาดรวมของพื้นที่เก็บข้อมูล (รวมถึงไดเร็กทอรี .git และไฟล์ที่ติดตาม) อยู่ที่ประมาณ 1.1 GB ดังนั้นฉันเดาว่ามันเป็นพื้นที่เก็บข้อมูลขนาดใหญ่ ;-) - person midtiby; 30.01.2011
comment
@MarkLongair: คุณช่วยชีวิตฉันไว้ครับ! ฉันกำลังจะวิ่งไปที่ร้านและซื้อการอัพเกรด RAM :D - person Andresch Serj; 16.01.2013
comment
โดยเฉพาะที่ Dreamhost ฉันต้องใช้ pack.windowMemory 10m pack.packSizeLimit 20m pack.deltacachesize = 20m pack.threads = 2 และ core.deltacachesize = 20m core.packedgitlimit = 30m ขอบคุณ @MarkLongair - person UrsoBranco; 19.07.2017

arrow_upward
23
arrow_downward

เนื่องจากไม่มีการเข้าถึงที่เก็บข้อมูลโดยตรงและด้วยเหตุนี้จึงไม่สามารถทำการแพ็กใหม่ได้ การทำโคลนแบบตื้นแล้วค่อยๆ ดึงข้อมูลในขณะที่ความลึกที่เพิ่มขึ้นช่วยฉันได้

git clone YOUR_REPO --depth=1
git fetch --depth=10
...
git fetch --depth=100
git fetch --unshallow    //Downloads all history allowing to push from repo

หวังว่ามันยังคงสามารถช่วยใครบางคนได้

person mmm    schedule 11.08.2013
comment
เป็นทางเลือกสุดท้ายสำหรับงานจำนวนมาก สิ่งนี้ได้ผลจริงๆ ขอบคุณ. - person Sajib Acharya; 17.05.2016
comment
git clone REPO --depth=1 ยังคงล้มเหลวสำหรับฉันโดยมีข้อผิดพลาด remote: aborting due to possible repository corruption on the remote side. - person Flimm; 04.10.2016
comment
เป็นวิธียุคหินเล็กน้อยในการทำเช่นนี้ แต่ก็ช่วยได้ เมื่อคิดว่าความลึก 300 เป็นจำนวนสูงสุดที่ฉันสามารถทำได้ด้วยเหตุผลบางอย่าง... - person Vinz; 16.08.2020

arrow_upward
15
arrow_downward

ฉันแก้ไขปัญหาโดยใช้ขั้นตอนต่อไปนี้

  1. มีการตรวจสอบพื้นที่เก็บข้อมูลจากเซิร์ฟเวอร์ไปยังเครื่องของฉันแล้ว (โดยใช้สำเนาดิบบน ssh)
  2. แพ็กที่เก็บในเครื่องใหม่
    git repack -a -d --window-memory 10m --max-pack-size 20m
  3. สร้างพื้นที่เก็บข้อมูลว่างบนเซิร์ฟเวอร์
    git init --bare
  4. พุชพื้นที่เก็บข้อมูลในเครื่องไปยังเซิร์ฟเวอร์
  5. ตรวจสอบว่าสามารถโคลนพื้นที่เก็บข้อมูลเซิร์ฟเวอร์ได้
person midtiby    schedule 28.01.2011
comment
ฉันดีใจที่ได้ยินว่าคุณได้รับการแก้ไขแล้ว แต่ฉันควรเตือนคุณว่าคุณจะประสบปัญหาเดิมอีกครั้งเมื่อเซิร์ฟเวอร์ตัดสินใจแพ็กพื้นที่เก็บข้อมูลใหม่ เป็นการดีที่สุดที่จะตั้งค่าตัวเลือกการกำหนดค่าในพื้นที่เก็บข้อมูลระยะไกล (เช่นตามที่แนะนำในคำตอบของฉัน) เพื่อที่ว่าเมื่อทำการแพ็กใหม่โดยอัตโนมัติ คุณจะยังคงมีหน่วยความจำไม่หมด - person Mark Longair; 14.09.2011

arrow_upward
6
arrow_downward

สิ่งนี้ไม่ได้ตอบคำถาม แต่อาจมีบางคนประสบปัญหา: การบรรจุใหม่อาจล้มเหลวบนเซิร์ฟเวอร์เมื่อ pack-objects ถูกยกเลิกโดยตัวทำลายหน่วยความจำบางประเภท (เช่นอันที่ใช้บน Dreamhost):

$ git clone project-url project-folder
Cloning into project-folder...
remote: Counting objects: 6606, done.
remote: Compressing objects: 100% (2903/2903), done.
error: pack-objects died of signal 9284.51 MiB | 2.15 MiB/s   
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

บน Dreamhost ดูเหมือนว่ามีสาเหตุมาจาก mmap รหัสการแพ็กใหม่ใช้ mmap เพื่อแมปเนื้อหาของไฟล์บางไฟล์ลงในหน่วยความจำ และเนื่องจากตัวจัดการหน่วยความจำไม่ฉลาดพอ มันจึงนับไฟล์ mmapped เป็นหน่วยความจำที่ใช้ ซึ่งจะทำให้กระบวนการ Git หยุดทำงานเมื่อพยายาม mmap ไฟล์ขนาดใหญ่

วิธีแก้ไขคือการรวบรวมไบนารี Git แบบกำหนดเองโดยปิดการรองรับ mmap (configure NO_MMAP=1)

person zoul    schedule 05.10.2011
comment
คุณรู้หรือไม่ว่าเป็นไปได้หรือไม่ที่จะเพิ่มตัวเลือก NO_MMAP=1 ให้กับการติดตั้ง git ที่มีอยู่? - person Max Williams; 03.11.2011
comment
ฉันไม่คิดอย่างนั้น ดูเหมือนว่ามาโครตัวประมวลผลล่วงหน้าจะนำไปสู่การสร้างโค้ดที่แตกต่างกัน แต่นั่นเป็นเพียงความคิดเห็น ฉันไม่ได้ค้นคว้าข้อมูล - person zoul; 03.11.2011

arrow_upward
1
arrow_downward

ฉันใช้ git เวอร์ชัน 1.7.0.4 และยอมรับคำสั่งนี้ อาจเป็นไปได้ว่า git เวอร์ชัน 1.6 ไม่ยอมรับคำสั่งนี้

ลองสร้างพื้นที่เก็บข้อมูลใหม่โดยมีการสุ่มคอมมิต จากนั้นทำการแพ็คใหม่ด้วยคำสั่งนี้

person matthias.lukaszek    schedule 28.01.2011
comment
คุณกำลังพูดถึงคำสั่งนี้หรือไม่? git repack -a -d --window-memory 10m --max-pack-size 100m - person Flimm; 04.10.2016

arrow_upward
1
arrow_downward

git config --global pack.window 0

person hetal    schedule 30.03.2020

arrow_upward
0
arrow_downward

ฉันมีปัญหาเดียวกันกับ Ubuntu 14.10 กับ git 2.1.0 บนที่เก็บส่วนตัว github.com (สงสัยว่าเป็นเราเตอร์ขององค์กร! ทำงานบนเครือข่าย wifi ที่แตกต่างกัน ยกเว้นในที่ทำงาน)

* GnuTLS recv error (-54): Error in the pull function.
* Closing connection 2jects:  31% (183/589)   
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header

วิธีแก้ปัญหาของฉันคือการคอมไพล์โคลนโดยใช้ ssh (ฉันตั้งค่าคีย์ ssh* ไว้ล่วงหน้า) เช่นนี้

โคลนคอมไพล์ https://github.com/USERNAME/REPOSITORYNAME.git

กลายเป็น:

git clone [email protected]:ชื่อผู้ใช้/REPOSITORYNAME.git

*: (กำลังสร้างคีย์ ssh)

ssh-keygen -t rsa -C "[email protected]"

จากนั้นเข้าสู่ระบบ GitHub ในการตั้งค่า นำเข้าคีย์ ssh และนำเข้าจาก ~/.ssh/id_rsa.pub

person arcol    schedule 28.04.2015
comment
ฉันได้ยินมาว่าเราเตอร์ระดับองค์กรทำการสแกนเนื้อหาและตัดการเชื่อมต่อสำหรับ HTTP แต่ไม่เคยใช้ HTTPS เลย เราเตอร์ของคุณถอดรหัสและเข้ารหัสการรับส่งข้อมูล HTTPS อีกครั้งด้วยหรือไม่ - person Rup; 30.04.2015
comment
รูป: มีเราเตอร์สองตัวที่เกี่ยวข้องก่อนที่จะใช้อินเทอร์เน็ต สัปดาห์หน้า ฉันจะตรวจสอบว่าการตั้งค่าของบริษัทนั้นเป็นอย่างไร ฉันตรวจสอบแล้วว่ามันไม่ได้ล้มเหลวที่อื่น (เครือข่าย wifi อื่น ๆ) เฉพาะที่บริษัทนั้น ๆ เท่านั้น - person arcol; 01.05.2015