打分系統源碼

1. 微信在線考試系統自己能做嗎

當然能自己做，而且操作非常簡單！

在線考試系統平台相對於微信來說是一個獨立的軟體，二者本沒有什麼關聯。但是在完成在線考試系統的試卷後，能夠自動生成考試二維碼以及網頁鏈接，將二維碼或鏈接在微信中進行轉發，考生就可以直接通過微信掃一掃功能或直接訪問該鏈接來完成在線考試。這樣使得微信作為一個紐帶，將考生與在線考試系統關聯在一起。

使用任意一個在線考試系統平台即可達成這個目標，為了方便起見，這里我們以輕速雲在線考試系統為例，介紹一下手機微信在線考試系統怎麼製作。

1、注冊並登錄到輕速雲在線考試系統後台，使用管理後台的各項考試管理功能來創建在線考試試卷。

2、使用「我的題庫」功能來創建題庫，將考試所需要使用的題目保存在題庫中，留待後續使用。

3、使用「我的試卷」進行在線考試試卷創建操作。如果需要創建僅針對於內部考試的非公開試卷，那麼需要進行步驟4的內容來創建成員，否則可以跳過步驟4。

4、在系統管理菜單下找到「成員管理」，通過在線添加或者導入的方式來完成考試成員的信息錄入。之後，每個成員都有獨立的賬號密碼用來登錄考試系統來完成考試。也可以不進行成員信息添加，而是在學員設置管理中開啟微信登錄直接注冊功能，讓系統拉取學員的微信信息來完成自助注冊。

5、從步驟2中創建的題庫里選擇具體的題目添加到試卷中，然後進行分值設定以及題目的排序操作。

6、通過「考試設置」來完成在線考試的環境配置，可以根據需求來調整多項內容。

7、公開試卷需要配置採集信息，讓考生填寫個人信息;而非公開試卷則需要確定考生名單，邀請需要考試的成員來參加考試。

8、發布試卷後系統自動生成多項考試入口，保存考試入口，在微信中進行傳播。

9、考生可以在微信信息中直接藉由訪問考試入口參加考試，也可以通過掃描或識別二維碼的方式來參加考試。

10、考試結束後考生答卷會自動上傳，管理員仍舊通過在線考試系統的管理後台來完成答卷的批閱、回收以及統計分析等工作。

以上就是輕速雲微信在線考試系統的製作方法，過程還是很簡單的。多使用幾次熟悉了信息的導入操作，創建試卷還會更快一些。

2. 有免費的在線考試系統推薦嗎

嗯，這個我知道，我們集團在用的優考試在線考試系統就不錯。優考試區域網和在線的我們集團都有用。那跟大家說一下使用感受吧！
1、優考試區域網就是，一個出題者端和一個考試者端，能在區域網裡面用的。
1.1 快速導入試題，形成試題庫：優考試支持Excel文件導入試題，只需要經過簡單的編輯，就能從原有的word 文檔或者Excel表格中編輯成優考試可導入的Excel格式，能快速的導入試題， 一次導入就能導入幾百題，上千題的題庫導入僅需要一分鍾。
2、說一下在線的吧。操作更方便。
出題者身份在使用系統的時候，可以創建題庫，直接EXCEL表導入試題，方便快捷，然互用來組卷，試卷組織好後，添加學生的信息，大致包括學生的姓名以及聯系方式等等，添加信息的目的是為了通過系統來通知學生只老師設置好的試卷范圍進行試卷作答。學生身份在使用系統時，除了可以完成老師布置的試卷題目，也可以自己在系統的題庫中搜索想要練習的題目來作答，作答結束後，也會有相應的分數和題目解析！考試的組織可以隨時隨地！考試的作答在設定的時間范圍內，隨時隨地！
3、最大的亮點就是可以手機微信考試，掃碼考試，打開試卷鏈接就可以考試。
4、可以試用30天，什麼功能都可以試，還可以定製。很贊

3. linux系統的OOM Killer處理機制

最近有位 VPS 客戶抱怨 Mysql 無緣無故掛掉，還有位客戶抱怨 VPS 經常死機，登陸到終端看了一下，都是常見的 Out of memory 問題。這通常是因為某時刻應用程序大量請求內存導致系統內存不足造成的，這通常會觸發 Linux 內核里的 Out of Memory (OOM) killer，OOM killer 會殺掉某個進程以騰出內存留給系統用，不致於讓系統立刻崩潰。如果檢查相關的日誌文件(/var/log/messages)就會看到下面類似的 Out of memory: Kill process 信息：
...
Out of memory: Kill process 9682 (mysqld) score 9 or sacrifice child
Killed process 9682, UID 27, (mysqld) total-vm:47388kB, anon-rss:3744kB, file-rss:80kB
httpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
httpd cpuset=/ mems_allowed=0
Pid: 8911, comm: httpd Not tainted 2.6.32-279.1.1.el6.i686 #1
...
21556 total pagecache pages
21049 pages in swap cache
Swap cache stats: add 12819103, delete 12798054, find 3188096/4634617
Free swap = 0kB
Total swap = 524280kB
131071 pages RAM
0 pages HighMem
3673 pages reserved
67960 pages shared
124940 pages non-shared
Linux 內核根據應用程序的要求分配內存，通常來說應用程序分配了內存但是並沒有實際全部使用，為了提高性能，這部分沒用的內存可以留作它用，這部分內存是屬於每個進程的，內核直接回收利用的話比較麻煩，所以內核採用一種過度分配內存(over-commit memory)的辦法來間接利用這部分 「空閑」 的內存，提高整體內存的使用效率。一般來說這樣做沒有問題，但當大多數應用程序都消耗完自己的內存的時候麻煩就來了，因為這些應用程序的內存需求加起來超出了物理內存(包括 swap)的容量，內核(OOM killer)必須殺掉一些進程才能騰出空間保障系統正常運行。用銀行的例子來講可能更容易懂一些，部分人取錢的時候銀行不怕，銀行有足夠的存款應付，當全國人民(或者絕大多數)都取錢而且每個人都想把自己錢取完的時候銀行的麻煩就來了，銀行實際上是沒有這么多錢給大家取的。
內核檢測到系統內存不足、挑選並殺掉某個進程的過程可以參考內核源代碼 linux/mm/oom_kill.c，當系統內存不足的時候，out_of_memory() 被觸發，然後調用 select_bad_process() 選擇一個 「bad」 進程殺掉，如何判斷和選擇一個 「bad」 進程呢，總不能隨機選吧?挑選的過程由 oom_badness() 決定，挑選的演算法和想法都很簡單很朴實：最 bad 的那個進程就是那個最佔用內存的進程。
/**
* oom_badness - heuristic function to determine which candidate task to kill
* @p: task struct of which task we should calculate
* @totalpages: total present RAM allowed for page allocation
*
* The heuristic for determining which task to kill is made to be as simple and
* predictable as possible. The goal is to return the highest value for the
* task consuming the most memory to avoid subsequent oom failures.
*/
unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,
const nodemask_t *nodemask, unsigned long totalpages)
{
long points;
long adj;
if (oom_unkillable_task(p, memcg, nodemask))
return 0;
p = find_lock_task_mm(p);
if (!p)
return 0;
adj = (long)p-signal-oom_score_adj;
if (adj == OOM_SCORE_ADJ_MIN) {
task_unlock(p);
return 0;
}
/*
* The baseline for the badness score is the proportion of RAM that each
* task's rss, pagetable and swap space use.
*/
points = get_mm_rss(p-mm) + p-mm-nr_ptes +
get_mm_counter(p-mm, MM_SWAPENTS);
task_unlock(p);
/*
* Root processes get 3% bonus, just like the __vm_enough_memory()
* implementation used by LSMs.
*/
if (has_capability_noaudit(p, CAP_SYS_ADMIN))
adj -= 30;
/* Normalize to oom_score_adj units */
adj *= totalpages / 1000;
points += adj;
/*
* Never return 0 for an eligible task regardless of the root bonus and
* oom_score_adj (oom_score_adj can't be OOM_SCORE_ADJ_MIN here).
*/
return points 0 ? points : 1;
}
上面代碼里的注釋寫的很明白，理解了這個演算法我們就理解了為啥 MySQL 躺著也能中槍了，因為它的體積總是最大(一般來說它在系統上佔用內存最多)，所以如果 Out of Memeory (OOM) 的話總是不幸第一個被 kill 掉。解決這個問題最簡單的辦法就是增加內存，或者想辦法優化 MySQL 使其佔用更少的內存，除了優化 MySQL 外還可以優化系統(優化 Debian 5，優化 CentOS 5.x)，讓系統盡可能使用少的內存以便應用程序(如 MySQL) 能使用更多的內存，還有一個臨時的辦法就是調整內核參數，讓 MySQL 進程不容易被 OOM killer 發現。
我們可以通過一些內核參數來調整 OOM killer 的行為，避免系統在那裡不停的殺進程。比如我們可以在觸發 OOM 後立刻觸發 kernel panic，kernel panic 10秒後自動重啟系統。
# sysctl -w vm.panic_on_oom=1
vm.panic_on_oom = 1
# sysctl -w kernel.panic=10
kernel.panic = 10
# echo "vm.panic_on_oom=1" /etc/sysctl.conf
# echo "kernel.panic=10" /etc/sysctl.conf
從上面的 oom_kill.c 代碼里可以看到 oom_badness() 給每個進程打分，根據 points 的高低來決定殺哪個進程，這個 points 可以根據 adj 調節，root 許可權的進程通常被認為很重要，不應該被輕易殺掉，所以打分的時候可以得到 3% 的優惠(adj -= 30; 分數越低越不容易被殺掉)。我們可以在用戶空間通過操作每個進程的 oom_adj 內核參數來決定哪些進程不這么容易被 OOM killer 選中殺掉。比如，如果不想 MySQL 進程被輕易殺掉的話可以找到 MySQL 運行的進程號後，調整 oom_score_adj 為 -15(注意 points 越小越不容易被殺)：
# ps aux | grep mysqld
mysql 2196 1.6 2.1 623800 44876 ? Ssl 09:42 0:00 /usr/sbin/mysqld
# cat /proc/2196/oom_score_adj
0
# echo -15 /proc/2196/oom_score_adj
當然，如果需要的話可以完全關閉 OOM killer(不推薦用在生產環境)：
# sysctl -w vm.overcommit_memory=2
# echo "vm.overcommit_memory=2" /etc/sysctl.conf
我們知道了在用戶空間可以通過操作每個進程的 oom_adj 內核參數來調整進程的分數，這個分數也可以通過 oom_score 這個內核參數看到，比如查看進程號為981的 omm_score，這個分數被上面提到的 omm_score_adj 參數調整後(-15)，就變成了3：
# cat /proc/981/oom_score
18
# echo -15 /proc/981/oom_score_adj
# cat /proc/981/oom_score
3
下面這個 bash 腳本可用來列印當前系統上 oom_score 分數最高(最容易被 OOM Killer 殺掉)的進程：
# vi oomscore.sh
#!/bin/bash
for proc in $(find /proc -maxdepth 1 -regex '/proc/[0-9]+'); do
printf "%2d %5d %sn"
"$(cat $proc/oom_score)"
"$(basename $proc)"
"$(cat $proc/cmdline | tr '' ' ' | head -c 50)"
done 2/dev/null | sort -nr | head -n 10
# chmod +x oomscore.sh
# ./oomscore.sh
18 981 /usr/sbin/mysqld
4 31359 -bash
4 31056 -bash
1 31358 sshd: root@pts/6
1 31244 sshd: vpsee [priv]
1 31159 -bash
1 31158 sudo -i
1 31055 sshd: root@pts/3
1 30912 sshd: vpsee [priv]
1 29547 /usr/sbin/sshd -D